View MT90883_1061480.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

MT90880/1/2/3 TDM to Packet Processors
Data Sheet Features
* * * * * * * * WAN interface, consisting of 32 input and output streams at 2.048 or 8.192 Mbs Up to 1024 bi-directional 64 Kbs channels N * 64 Kbs trunking of channels across any stream and channel 1 K by 1 K non-blocking TDM switch Local TDM interface, with 32 streams at 2.048, 4.096 and 8.192 Mbs Flexible, multi-protocol packet encapsulation Dual 100 Mbs MII interfaces for redundancy or for load balancing Quality of service features, including weighted fair queuing, strict priority and queue size limit thresholds High performance 33 MHz / 66 MHz 32 bit PCI bus Integral Stratum 4E PLL for synchronisation to the TDM domain Power consumption of less than 0.75 W Ordering Information MT90880B/IG/BP1N MT90881A/IG/BP1N MT90882B/IG/BP1N MT90883A/IG/BP1N 456 ball PBGA 456 ball PBGA 456 ball PBGA 456 ball PBGA
December 2004
-40C to +85C
Applications
* * * * * Packet backplane interconnection Circuit Emulation over packet domain Internet Off-load Remote Access Concentrators H.100/H.110 extension and expansion
* * *
Host Control/Data Interface 32 bit, 33MHz / 66MHz 32 PCI
WAN Access Interface
32 ST-Bus TDM ports (1024 bi-directional channels)
Administration
PCI Interface
Packet Switch Fabric Interface
Dual Redundant 100 Mbit/s MII Interfaces
1Kx1K TDM Switch
Packetizing and Circuit Emulation
Dual Packet Interface MAC
TDM ReFormatter
Memory Manager
Local TDM Interface Packet Memory e.g. for connection to local resource pool 0.125 - 8 MBytes SSRAM
Figure 1 - MT90880 High Level Overview 1
Zarlink Semiconductor Inc. Zarlink, ZL and the Zarlink Semiconductor logo are trademarks of Zarlink Semiconductor Inc. Copyright 2003-2004, Zarlink Semiconductor Inc. All Rights Reserved.
MT90880/1/2/3
Description
Data Sheet
The MT9088x is a family of highly functional TDM to Packet bridging devices. It provides a bridge between a WAN environment based on constant bit rate TDM streams and a packet domain based on Ethernet technology. It is capable of assembling user-defined packets of TDM traffic from the WAN Access Interface and transmitting them from the Ethernet interfaces using a variety of protocols. If external processing is required (e.g., HDLC or modem termination) the traffic can be switched to a local interface using the internal TDM switch. Packets received from the Ethernet interfaces are parsed to determine the egress destination, and are appropriately queued either to the WAN Access Interface or to the PCI interface. An integrated DMA controller is used to transfer packets to and from the PCI interface with a minimum of CPU intervention.
Variants
There are four device variants in the MT9088x family: * * * * MT908801024 bi-directional channels, integral TDM switch MT908811024 bi-directional channels, no TDM switch MT90882256 bi-directional channels, integral TDM switch MT90883256 bi-directional channels, no TDM switch Feature No. of WAN streams Local Port No. of Available Channels TDM Switch Availability PCI Interface MII Interface RMII Interface JTAG MT90880 32 Yes 1024 Master mode only 33 / 66 MHz Yes Yes Yes MT90881 32 No 1024 Not Available 33 / 66 MHz Yes Yes Yes MT90882 8 Yes 256 Master mode only 33 / 66 MHz Yes Yes Yes MT90883 8 No 256 Not Available 33 / 66 MHz Yes Yes Yes
Table 1 - Variant Options
Related Documents
This data sheet should be read in conjunction with the following related documents and application notes: Title 1. MT9088x Programmers Model 2. MT9088x API User Guide 3. MSAN-198 - Performing Clock Recovery for Circuit Emulation when using the MT90880 4. MSAN-199 - Unstructured Circuit Emulation Using the MT90880 5. MSAN-200 - MT90880 TDM Replacement Packet Backplane Author Zarlink Zarlink Zarlink Zarlink Zarlink Document Number DM5708 DM5805 AN5789 AN5790 AN5791 Issue / Date 1.0, Aug. 2002 1.0, Sept. 2002 1, Aug. 2002 1, Aug. 2002 1, Aug. 2002
Table 2 - Related Documents
2
Zarlink Semiconductor Inc.
MT90880/1/2/3
The following external documents and standards are referenced in this data sheet: Title 1. Local and Metropolitan Area Networks, Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications 2. PCI Local Bus Specification 3.
RMII TM Specification
Data Sheet
Author IEEE
Document Number IEEE 802.3u
Issue / Date 1995
4. Test Access Port and Boundary Scan Architecture 5. Circuit Emulation Service Interoperability Specification 6. Specifications of (DBCES) Dynamic Bandwidth Utilization - in 64 KBPS Time Slot Trunking over ATM - Using CES 7. ST-BUS Generic Device Specification 8. H.110 Hardware Compatibility Specification: CT Bus 9. H-MVIP Standard 10. Clocks for the Synchronized Network: Common Generic Criteria
PCI SIG RMII consortium IEEE ATM Forum ATM Forum
2.2 Rev 1.2, March 1998 IEEE 1149.1 af-vtoa-0078 af-vtoa-0085 1990 Ver 2.0, Jan. 1997 July 1997
Mitel ECTF GO-MVIP Telcordia
ITU-T ITU-T
MSAN-126
11. The Control of Jitter and Wander within digital networks which are based on the 2048 Kbs hierarchy 12. The Control of Jitter and Wander within digital networks which are based on the 1544 Kbs hierarchy
GR-1244CORE G.823 G.824
Rev. B, June 1995 Rev. 1.0, 1997 Rel. 1.1a, Jan. '97 Iss. 2, Dec. 2000 2000 2000
Table 3 - Referenced Documents
3
Zarlink Semiconductor Inc.
MT90880/1/2/3 Table of Contents
Data Sheet
1.0 Changes Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.0 Physical Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.0 External Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 WAN Access Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Local TDM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 Packet Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1 MII Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2 RMII Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 PCI Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.5 External Memory Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.6 System Control Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7 Test Facilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7.1 JTAG Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7.2 Test Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7.3 Test Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.8 Power and Ground Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.0 Typical Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 Packet Backplane Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Circuit Emulation Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Internet Off-load. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4 Remote Access Concentration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5 Local Resource Pool Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.6 H.100/H.110 Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.7 H.100/H.110 Expansion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.0 Functional Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2 Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.1 WAN Access Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.2 Packet Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.3 CPU Packet Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.4 Packet Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.5 Call Setup and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3 Data and Control Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.4 Packet Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.4.1 Payload Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.4.2 Packet Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.4.3 Context Descriptor Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.5 Context Negotiation and Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.5.2 New Context Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.5.3 Context Modification (Addition or deletion of physical channels) . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.5.4 Context Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.5 Context Cleardown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.0 Functional Block Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1 WAN Interface and Multiplexers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1.1 Port Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1.2 Operational Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.2 TDM Cross-Connect Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2.1 Multiplexing and Blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2.2 Re-ordering Timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2.3 Channel Broadcast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.3 WAN Receive and Transmit Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4
Zarlink Semiconductor Inc.
MT90880/1/2/3 Table of Contents
Data Sheet
6.4 Operation of the WAN Receive Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4.1 Context Control in the WAN Receive/Transmit Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4.2 Jitter Buffer Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.5 Queue Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.5.1 Queues to the Packet Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.5.2 Queues to PCI Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.5.3 Queues to WAN Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.6 Packet Transmit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.6.1 Protocol Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.6.2 Shadow Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.7 Ethernet MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.8 Packet Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.8.1 Pattern Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.8.2 Example Classification Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.9 Memory Management Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.9.1 External Memory Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.9.2 Granule Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.9.3 Connecting the MT9088x to External Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.9.4 External Memory Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.10 PCI Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.10.1 Address and Data Width support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.10.2 Target Transaction Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.10.3 Master Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.10.4 Configuration and Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.10.5 Signalling Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.10.6 Open Drain Circuitry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.11 DMA Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.11.1 DMA Descriptor Rings and Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.11.2 Data Transfer from CPU to MT90880 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.11.3 Data Transfer from MT90880 to CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.12 Board Level Test Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.12.1 JTAG Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.12.2 Test Access Port (TAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.12.3 Test Access Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.13 DPLL Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.13.1 Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.13.2 Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.13.3 Free-run Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.13.4 DPLL Performance Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.0 Memory Map and Register definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.0 Special Note to Users: MT9088x handling of received corrupted Ethernet packets and dealing with the next valid packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.1 Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.2 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.0 DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.0.1 Input Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 9.0.2 Output Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 10.0 AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 10.1 WAN Access Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 10.1.1 Slave Clock Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 10.1.2 Clock Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.2 Local TDM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5
Zarlink Semiconductor Inc.
MT90880/1/2/3 Table of Contents
Data Sheet
10.3 Packet Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 10.3.1 MII Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 10.3.2 MII Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.3.3 RMII Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 10.4 External Memory Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 10.5 System Control Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 10.6 JTAG Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 11.0 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6
Zarlink Semiconductor Inc.
MT90880/1/2/3 List of Figures
Data Sheet
Figure 1 - MT90880 High Level Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Figure 2 - Package View and Ball Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Figure 2 - Multiservice Access Platform using the MT90880 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figure 3 - Circuit Emulation Services over the packet network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figure 4 - Internet Off-load solution using the MT90880 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figure 5 - Remote Access Concentrator using the MT90880 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 6 - Use of a Local Resource Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 7 - H.100/H.110 Extension over Ethernet link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 8 - H.100/H.110 Expansion using Ethernet Switching Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figure 9 - MT9088x Family Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 10 - MT90880 Data and Control Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 11 - WAN to Packet Data and Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Figure 12 - Packet to WAN Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Figure 13 - WAN to Packet Data Flow via Local Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figure 14 - Packet to WAN Data Flow via Local Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 15 - PCI to Packet Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 16 - Packet to PCI Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figure 17 - Channel and stream order for packet formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Figure 18 - Packet Structure for MT9088x Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Figure 19 - Context Descriptor Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Figure 20 - Connecting to Framers in Synchronous Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figure 21 - Connecting to an H.100/H.110 Backplane in Synchronous Slave Mode . . . . . . . . . . . . . . . . . . . . . . . 43 Figure 22 - Connecting Framers to the MT90880 in Asynchronous Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Figure 23 - TDM Switch Access Multiplexers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figure 24 - Operation of the WAN Receive Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Figure 25 - Context Look-Up Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Figure 26 - Packet Classification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figure 27 - PDV Supported for Different Memory and Packet Payload Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figure 28 - Connecting the MT90880 to a Single External Memory Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figure 29 - Connecting the MT90880 to Multiple External Memory Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Figure 30 - MT90880 Memory and Register Space Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Figure 31 - pci_serr#, pci_inta# Open Drain Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 32 - DMA Transfer to/from System Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 33 - Descriptor Ring Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figure 34 - Descriptor List Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Figure 35 - DMA Operation from CPU Packet Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Figure 36 - DPLL Jitter Transfer Function Diagram Across a Wide Range of Frequencies. . . . . . . . . . . . . . . . . . 77 Figure 37 - Detailed DPLL Jitter Transfer Function Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Figure 38 - WAN Bus Slave Mode Timing at 2.048 Mbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Figure 39 - WAN Bus Slave Mode Timing at 2.048 Mbs Generic E1 Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Figure 40 - WAN Bus Slave Timing at 8.192 Mbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Figure 41 - WAN Bus Clock Master Mode Timing at 2.048 Mbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Figure 42 - WAN Bus Clock Master Mode at 2.048 Mbs - Generic E1 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figure 43 - WAN Bus Clock Master Mode Timing at 8.192 Mbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figure 44 - Local Bus Timing at 2.048 Mbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Figure 45 - Local Bus Timing at 4.096 Mbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Figure 46 - Local Bus Timing at 8.192 Mbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Figure 48 - MII Port Receive Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7
Zarlink Semiconductor Inc.
MT90880/1/2/3 List of Figures
Data Sheet
Figure 49 - External RAM Single Cycle Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Figure 50 - External RAM Multi Cycle Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Figure 51 - External RAM Single Cycle Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Figure 52 - External RAM Multi Cycle Write. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Figure 53 - JTAG Clock and Reset Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8
Zarlink Semiconductor Inc.
MT90880/1/2/3 List of Tables
Data Sheet
Table 1 - Variant Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Table 2 - Related Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Table 3 - Referenced Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Table 4 - WAN Access Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Table 5 - Local TDM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Table 6 - MII Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Table 7 - RMII Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Table 8 - PCI Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Table 9 - External Memory Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Table 10 - System Control Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Table 11 - JTAG Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Table 12 - Test Facilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Table 13 - Bootstrap Pin Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Table 14 - Power and Ground Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 15 - New Context Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Table 16 - Context Modification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Table 17 - Context Teardown Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Table 18 - Input Data Formats accepted by the MT9088x family. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Table 19 - Configuration of Packet Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Table 20 - Example of Weighted Fair Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Table 21 - Pattern Matching for Example Traffic Class 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Table 22 - Control Register Fields for Example Traffic Class 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Table 23 - Pattern Matching for Example Traffic Class 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Table 24 - Control Register Fields for Example Traffic Class 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Table 25 - Pattern Matching for Example Traffic Class 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Table 26 - Control Register Fields for Example Traffic Class 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Table 27 - Pattern Matching for Example Traffic Class 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Table 28 - Control Register Fields for Example Traffic Class 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Table 29 - Total Available Memory Size, Using Four External SSRAM Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Table 30 - DPLL Performance Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Table 31 - WAN Access Interface Timing - Slave Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Table 32 - WAN Access Interface Timing - Master Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Table 33 - Local TDM Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Table 34 - Packet Interface Timing - MII Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Table 35 - Packet Interface Timing - MII Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Table 36 - Packet Interface Timing - RMII Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Table 37 - External Memory Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Table 38 - System Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Table 39 - JTAG Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9
Zarlink Semiconductor Inc.
MT90880/1/2/3
1.0 Changes Summary
Data Sheet
The following table captures the changes from the November 2004 issue.
Page 17 71 Table 8
Item
Change Signals pci_req#, pci_serr# and pci_inta# changed from open drain to normal I/O. Addition of Section 6.10.6, "Open Drain Circuitry" showing external open drain buffer for signals pci_serr# and pci_inta#.
"Open Drain Circuitry"
The following table captures the changes from the June 2004 issue.
Page 81
Item "DC Characteristics" Table
Change DC Electrical Characterisitics were changed due to incorrect units listed.
10
Zarlink Semiconductor Inc.
MT90880/1/2/3
2.0 Physical Specification
Data Sheet
The device is contained in a 456-ball plastic ball grid array (456 PBGA) package: * * * * * * Body Size: 27 mm x 27 mm Ball Count: 456 Ball Pitch: 1.0 mm Ball Matrix: 26 x 26 (partially populated with a 6 x 6 GND matrix in the centre) Ball Diameter 0.63 mm Total Package Thickness 2.03 mm
Package is viewed from the top side (e.g,. through top of the package). Note ball A1 is non-chamfered corner.
Figure 2 - Package View and Ball Positions
11
Zarlink Semiconductor Inc.
MT90880/1/2/3
3.0 External Interface Description
Data Sheet
The following key applies to all tables: O I D U Output Input internal 100 K pull-down resistor present internal 100 K pull-up resistor present
3.1
WAN Access Interface
All WAN Access Interface signals are 5 V tolerant. All WAN Access Interface outputs are high impedance while S_RST is low. Signal WAN_STO[31:24] I/O O Package Balls T22 [31], U26 [30], R26 [29], P26 [28], N25 [27], M24 [26], L25 [25], K24 [24] J25 [23], G26 [22], G25 [21], G24 [20], D26 [19], D22 [18], B24 [17], B23 [16], B22 [15], A22 [14], E18 [13], E17 [12], C18 [11], E16 [10], A17 [9], A16 [8] B15 [7], A14 [6], B13 [5], B12 [4], E11 [3], A10 [2], E10 [1], E9 [0] W26 [31], U25 [30], R25 [29], M23 [28], L23 [27], L22 [26], K22 [25], K25 [24] J22 [23], H25 [22], G23 [21], F25 [20], E25 [19], C24 [18], D21 [17], E20 [16], D20 [15], D19 [14], A21 [13], C19 [12], A19 [11], A18 [10], B17 [9], E15 [8] D14 [7], B14 [6], D12 [5], A12 [4], A11 [3], C11 [2], A9 [1], C9 [0] W25 [31], U24 [30], R24 [29], P25 [28], N26 [27], M25 [26], L26 [25], K26 [24] J26 [23], H26 [22], H24 [21], F26 [20], F23 [19], C26 [18], A25 [17], C23 [16], C22 [15], C21 [14], C20 [13], D18 [12], B19 [11], D17 [10], D16 [9], B16 [8], C15 [7], C14 [6], A13 [5], C13 [4], D11 [3], D10 [2], C10 [1], D9 [0] U22 [31], V26 [30], N23 [29], P24 [28], M22 [27], N24 [26], K23 [25], L24 [24] Table 4 - WAN Access Interface Description WAN Interface serial output streams Operate at 2.048 Mbs All variants WAN Interface serial output streams Operate at 2.048 Mbs MT90880 and MT90881 variants only. WAN Interface serial output streams Operate at 2.048 and 8.192 Mbs MT90880 and MT90881 variants only. WAN Interface serial input streams Operate at 2.048 Mbs All variants. WAN Interface serial input streams Operate at 2.048 Mbs MT90880 and MT90881 variants only WAN Interface serial input streams Operate at 2.048 and 8.192 Mbs MT90880 and MT90881 variants only WAN Interface frame pulse inputs. Programmable as active high or low. All variants WAN Interface frame pulse inputs. Programmable as active high or low. MT90880 and MT90881 variants only.
WAN_STO[23:8]
O
WAN_STO[7:0]
O
WAN_STI[31:24]
ID
WAN_STI[23:8]
ID
WAN_STI[7:0]
ID
WAN_FRMI[31:24]
ID
WAN_FRMI[23:0]
ID
WAN_CLKI[31:24]
ID
WAN Interface clock inputs. Programmable as active high or low. All variants
12
Zarlink Semiconductor Inc.
MT90880/1/2/3
Signal WAN_CLKI[23:0] I/O ID Package Balls J23 [23], J24 [22], H22 [21], G22 [20], E26 [19], E24 [18], A26 [17], A24 [16], A23 [15], E19 [14], B21 [13], B20 [12], A20 [11], B18 [10], C17 [9], C16 [8], D15 [7], A15 [6], D13 [5], E12 [4], C12 [3], B11 [2], B10 [1], B9 [0] V23 V22
Data Sheet
Description WAN Interface clock inputs. Programmable as active high or low. MT90880 and MT90881 variants only.
WAN_FRMO WAN_CLKO
O O
WAN Interface master frame pulse output WAN Interface master clock output
Table 4 - WAN Access Interface (continued)
3.2
Local TDM Interface
All Local TDM Interface signals are 5 V tolerant. All Local TDM Interface outputs are high impedance while S_RST is low. Signal LOC_STI [31:24] I/O ID Package Balls B6 [31], C7 [30], A5 [29], C5 [28], A4 [27], B4 [26], A3 [25], B3 [24] D5 [23], D4 [22], B2 [21], F4 [20], D3 [19], G5 [18], E3 [17], G4 [16] H5 [15], F3 [14], F2 [13], J5 [12], J4 [11], K5 [10], H2 [9], H1 [8] J2 [7], J1 [6], K3 [5], K1 [4], M4 [3], N4 [2], M3 [1], M1 [0] E8 [31], D7 [30], C6 [29], B5 [28], E7 [27], D6 [26], C4 [25], A2 [24] Description Local TDM interface serial input streams. Operate at 2.048 Mbs MT90880 and MT90882 variants only. Local TDM interface serial input streams. Operate at 2.048 Mbs MT90880 variant only. Local TDM interface serial input streams Operate at 2.048 and 4.096 Mbs MT90880 variant only Local TDM interface serial input streams Operate at 2.048, 4.096 and 8.192 Mbs MT90880 variant only Local TDM interface serial output streams Operate at 2.048 Mbs MT90880 and MT90882 variants only Local TDM interface serial output streams Operate at 2.048 Mbs MT90880 variant only Local TDM interface serial output streams Operate at 2.048 and 4.096 Mbs MT90880 variant only
LOC_STI [23:16]
ID
LOC_STI [15:8]
ID
LOC_STI [7:0]
ID
LOC_STO [31:24]
O
LOC_STO [23:16]
O
C3 [23], E4 [22], A1 [21], B1 [20], C2 [19], C1 [18], D2 [17], D1 [16]
LOC_STO [15:8]
O
H4 [15], E1 [14], G3 [13], F1 [12], G2 [11], H3 [10], G1 [9], K4 [8]
Table 5 - Local TDM Interface
13
Zarlink Semiconductor Inc.
MT90880/1/2/3
Signal LOC_STO [7:0] I/O O Package Balls L5 [7], L4 [6], K2 [5], L3 [4], L2 [3], P4 [2], M2 [1], N3 [0] Description
Data Sheet
Local TDM interface serial output streams Operate at 2.048, 4.096 and 8.192 Mbs MT90880 variant only TDM interface 4.096 MHz clock All variants 8 KHz frame pulse for C4OB clock All variants TDM interface 8.192 MHz clock All variants 8 KHz frame pulse for C8OB clock. All variants TDM interface 16.384 MHz clock All variants 8 KHz frame pulse for C16OB clock. All variants WAN and TDM serial output enable. High to enable outputs, low for high impedance. All variants
c4ob fp4ob c8ob fp8ob c16ob fp16ob ode
O O O O O O ID
B8 C8 A7 A6 B7 D8 A8
Table 5 - Local TDM Interface (continued)
3.3 3.3.1
Packet Interfaces MII Interfaces
Data for the MII packet switching is based on Specification IEEE Std 802.3u - 1995. The MII has separate transmit and receive circuits, and consequently the characteristics are shown in the relevant tables. All MII signals are 5 V tolerant. All MII outputs are high impedance while S_RST is low. Signal m_mdc m_mdio MII Port A m_mint0 m0_txd[3:0] m0_txen IU OU OU AF6 AC8 [3], AF5 [2], AE6 [1], AD7 [0] AD6 MII management interrupt for port A Transmit data Transmit enable Table 6 - MII Interfaces I/O O IOU AF9 AC10 Package Balls Description MII management data clock. Common for both MII ports. MII management data I/O Common for both MII ports; 2.5 MHz
14
Zarlink Semiconductor Inc.
MT90880/1/2/3
Signal m0_txclk m0_rxd[3:0] m0_rxdv m0_rxclk m0_rxer m0_crs m0_col MII Port B m_mint1 m1_txd[3:0] m1_txen m1_txclk m1_rxd[3:0] m1_rxdv m1_rxclk m1_rxer m1_crs m1_col IU OU OU IU IU ID IU ID ID ID AE11 AC11 [3], AE10 [2], AF10 [1], AD11 [0] AD10 AB12 AF12 [3], AD13 [2], AE13 [1], AF13 [0] AE12 AC13 AD12 AC12 AF11 I/O IU IU ID IU ID ID ID AB9 AF8 [3], AE8 [2], AE9 [1], AD9 [0] AF7 AB10 AD8 AC9 AE7 Package Balls Transmit clock Receive data Receive data valid Receive clock Receive error Carrier sense Collision detect Description
Data Sheet
MII management interrupt for port B Transmit data Transmit enable Transmit clock Receive data Receive data valid Receive clock Receive error Carrier sense Collision detect Table 6 - MII Interfaces (continued)
3.3.2
RMII Interfaces
The RMII is a low pin count MII interface. It has no defined standard, but the RMII Consortium publishes details (reference 3, Table 2). The MT90880 RMII Interface shares the same pins as the MII interface with the exception of the REF_CLK. The RMII comprises a low pin count Reduced Media Independent InterfaceTM (RMIITM) specification intended for use between Ethernet PHYs and Switch ASICs. Under IEEE 802.3u [2] an MII, comprised of 16 pins for data and control, is defined. In devices incorporating many MACs or PHY interfaces such as switches, the number of pins can add significant cost as the port counts increase. The purpose of this interface is to provide a low cost alternative to the IEEE 802.3u [2] MII. Architecturally, the RMII specification provides for an additional reconciliation layer on either side of the MII but can be implemented in the absence of an MII. The management interface (MDIO/MDC) is assumed to be identical to that defined in IEEE 802.3u [2]. All RMII signals are 5 V tolerant. All RMII outputs are high impedance while S_RST is low.
15
Zarlink Semiconductor Inc.
MT90880/1/2/3
Signal ref_clk I/O IU AB11 Package Balls Description
Data Sheet
Synchronous clock reference for receive, transmit and control interface. Common to both RMII ports.
RMII Port A rm0_rxd[1:0] rm0_rxdv/ crs rm0_txen rm0_txd[1:0] RMII Port B rm1_rxd[1:0] rm1_rxdv/ crs rm1_txen rm1_txd[1:0] IU ID OU OU AE13 [1], AF13 [0] AE12 AD10 AF10 [1], AD11 [0] Receive data Carrier sense & receive data valid Transmit enable Transmit data IU ID OU OU AE9 [1], AD9 [0] AF7 AD6 AE6 [1], AD7 [0] Receive data Carrier sense & receive data valid Transmit enable Transmit data
Table 7 - RMII Interface
3.4
PCI Interface
The PCI signals are NOT 5 V tolerant. All PCI outputs are high impedance while S_RST is low. Active low signals are designated by a # suffix, in accordance with the convention used in the PCI specification. Signal pci_clk pci_rst# pci_req# pci_gnt# pci_ad[31:0] I/O I I O I IO AF20 AE19 AC19 AD19 AE20 [31], AB19 [30], AF21 [29], AC20 [28], AD20 [27], AE21 [26], AF22 [25], AD21 [24], AF23 [23], AD22 [22], AE23 [21], AC21 [20], AE24 [19], AC22 [18], AD24 [17], AC23 [16], AC26 [15], AB25 [14], W23 [13], AA24 [12], AB26 [11], AA25 [10], Y24 [9], AA26 [8], V24 [7], U23 [6], V25 [5], T23 [4] T24 [3], R23 [2], T25 [1], T26 [0] AE22 [3], AB23 [2], Y23 [1], W24 [0] AC25 AE25 Package Balls PCI clock PCI reset PCI request PCI grant PCI address / data Description
pci_cbe[3:0]# pci_par pci_frame#
IO IO IO
PCI control / byte enable PCI parity PCI frame
16
Zarlink Semiconductor Inc.
MT90880/1/2/3
Signal pci_trdy# pci_irdy# pci_stop# pci_devsel# pci_idsel pci_perr# pci_serr# I/O IO IO IO IO I IO IO AA23 AF26 AC24 AE26 AB20 AD26 AB24 Package Balls Description PCI target ready PCI initiator ready PCI stop PCI device select PCI ID select PCI parity error
Data Sheet
PCI system error (NOT open drain. See "Open Drain Circuitry" on page 71) PCI lock. Refer to PCI spec section 2.2.3 PCI interrupt (NOT open drain. See "Open Drain Circuitry" on page 71) 33 MHz /66 MHz select Table 8 - PCI Interface
pci_lock# pci_inta# PCI_M66EN
IO IO IO
Y22 AF19 Y25
3.5
External Memory Interface
The external memory signals are NOT 5 V tolerant. Active low signals are designated by a # suffix, in accordance with the convention used in common memory data sheets Signal ram_d[31:0] I/O IOU Package Balls N2 [31], R4 [30], N1 [29], R5 [28], P1 [27], T4 [26], P2 [25], P3 [24], R1 [23], AB4 [22], AC2 [21], AD1 [20], AC3 [19], AD2 [18], AC4 [17], AE1 [16], AE2 [15], AD3 [14], AC5 [13], AF1 [12], AF2 [11], AC6 [10], AE3 [9], AF3 [8], AD4 [7], AB7 [6], AE4 [5], AF4 [4], AD5 [3], AC7 [2], AE5 [1], AB8 [0] T5 [22], R3 [21], U4 [20], T1 [19], U5 [18], T2 [17], T3 [16], U1 [15], U2 [14], U3 [13], V4 [12], V1 [11], V5 [10], V2 [9], W4 [8], W1 [7], W2 [6], Y1 [5], W5 [4], W3 [3], Y4 [2] AB3 Y5 [3], AA1 [2], Y3 [1], AA2 [0] AB1 [3], AA4 [2], AB2 [1], AC1 [0] Description Buffer memory data
ram_a[22:2]
O
Buffer memory address (up to 8 MBytes)
ram_adsc# ram_we[3:0]# ram_oe[3:0]#
OU OU OU
Buffer memory address status control Buffer memory write chip select Buffer memory read chip select
Table 9 - External Memory Interface
17
Zarlink Semiconductor Inc.
MT90880/1/2/3
3.6 System Control Interface
Data Sheet
The system signals are 5 V tolerant. RESOUT# is low while S_RST# is low. The core of the chip will be held in reset for 16348 S_CLK cycles after S_RST# has gone high and 16348 PCI_CLK cycles after PCI_RST# have gone high to allow the PLLs to lock. Signal s_clk s_rst# resout# I/O I I O B25 D24 C25 Package Balls System clock Reset input Reset PHY Table 10 - System Control Interface Description
3.7 3.7.1
Test Facilities JTAG Interface
All JTAG signals are 5 V tolerant. Signal jtag_trst# jtag_tck jtag_tms jtag_tdi jtag_tdo I/O I I I I O AB17 AB18 AC18 AD18 AE18 Package Balls Description JTAG reset. Must be pulled low externally for normal operation. JTAG test clock JTAG test mode select JTAG test data input JTAG test data output Table 11 - JTAG Interface
3.7.2
Test Facility
All test signals are 5 V tolerant except for IDDQ, SCLK_AT1 and PCLK_AT1. Signal t_mode[1:0] I/O IOU AF14 [1], AC14 [0] Width Description Test - Set Mode upon Reset 00 - PLL test mode 01 - Scan test mode 10 - Board level test mode 11 - Normal operation Test MUX output. Also used as bootstrap pins to configure the device following a reset.
t_d[15:0]
OU
AC15 [15], AE14 [14], AB15 [13], AD14 [12], AF15 [11], AE15 [10], AD15 [9], AF16 [8], AB16 [7], AE16 [6], AC17 [5], AD16 [4], AF17 [3], AE17 [2], AD17 [1], AF18 [0]
18
Zarlink Semiconductor Inc.
MT90880/1/2/3
Signal iddq sclk_AT1 I/O I O AD23 B26 Width Description IDDQ test enable.
Set low for normal operation.
Data Sheet
Analog test output for system clock PLL. Leave unconnected in normal operation. Analog test output for PCI clock PLL. Leave unconnected in normal operation. 66 MHz memory clock output. This is used for test purposes only. Leave unconnected in normal operation. Table 12 - Test Facilities
pclk_AT1
O
AF24
ram_clk
O
Y2
3.7.3
Test Operating Modes
1) Normal operating mode (T_MODE[1:0] = '11')
The device samples the T_D pins to determine the required operating mode shortly after reset is released. These pins are known as the "bootstrap controls". The device has internal pull-up (100 K 30%) resistors connected to the T_D bus pins. To pull-low connect a 10 K pull-down resistor to ground. Bootstrap controls are as follows: T_D 15 14 13:11 10:8 7 6 5 Reserved Reserved Reserved Selects delay of RAM_CLK output relative to S_CLK. Pull low to bypass PCI_CLK PLL. Pull low to bypass the S_CLK PLL. Controls m_mint0 and m_mint1 polarity - pull low for active low and leave unconnected for active high. Pull low to enable RAM_CLK output (otherwise it will be high impedance). Pull low for freeze enable. Pull low for simulation speed-up. This reduces the number of cycles that the chip is held in reset after S_RST# and PCI_RST# have gone high from 16348 to 256. This should not be used during normal operation, since the PLLs will not have time to lock. Reserved Table 13 - Bootstrap Pin Functions Leave unconnected in normal operation. Leave unconnected in normal operation. Leave unconnected in normal operation. See Table 21. Pull low for normal operation. Function Notes
4 3 2
Leave unconnected in normal operation. Leave unconnected in normal operation. Leave unconnected in normal operation.
0:1
19
Zarlink Semiconductor Inc.
MT90880/1/2/3
2) Board level continuity test mode (T_MODE[1:0] = '10')
Data Sheet
In continuity test mode the core of the chip is held in reset. Pin T_D[10] selects the board level test mode.
3) Scan test mode (T_MODE[1:0] = '01')
System clock and PCI clock PLLs are put into bypass mode. The core PCI and system resets are driven directly from the pins i.e. the logic which holds the resets asserted until the PLLs have had time to lock is disabled.
4) PLL test mode (T_MODE[1:0] = '00')
The core of the chip is held in reset. Test bus pins are configured for direct test access to the system clock and PCI clock PLLs.
3.8
Power and Ground Connections
Signal Package Balls AA5, AA22, AB5, AB6, AB13, AB14, AB21, AB22, E5, E6, E13, E14, E21, E22, F5, F22, M5, N5, N22, P5, P22, R22 AA3, E2, F24, H23, J3, L1, M26, P23, R2, V3, W22, Y26 L11, L12, L13, L14, L15, L16, M11, M12, M13, M14, M15, M16, N11, N12, N13, N14, N15, N16, P11, P12, P13, P14, P15, P16, R11, R12, R13, R14, R15, R16, T11, T12, T13, T14, T15, T16, AD25, E23 D25 AF25 D23, AC16 Table 14 - Power and Ground Connections Description 3.3 V VDD power supply 1.8 V VDD power supply 0 V power supply
VDD33 VDD18 GROUND
A1VDD A2VDD no connection
1.8 V VDD power supply 1.8 V VDD power supply
4.0
4.1
Typical Applications
Packet Backplane Interconnection
The MT9088x family can be used to entirely replace the TDM backplane infrastructure in a conventional computer telephony system with a packet backplane. This has several advantages: it is easily scalable, eliminates the timing problems in passing large TDM buses around the system, uses readily available and low-cost network hardware, and simplifies the provision of new services to customers. This type of structure can be used in applications as diverse as telephone switches, multi-service access platforms and voice over IP gateways. Figure 2 shows a multi-service access platform based on an Ethernet backplane using the MT90880.
20
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Line Input Card
MT9076 Framer MT90880 TDM-IP Processor
Remote Resource Pool
MT90880 TDM-IP Processor DSP modem pool
Line Input Card
MT9076 Framer MT90880 TDM-IP Processor
Remote Resource Pool
MT90880 TDM-IP Processor DSP codecs/ echo can.
PSTN
Line Input Card
MT9076 Framer MT90880 TDM-IP Processor
MVTX2604 Ethernet Switch
Remote Resource Pool
MT90880 TDM-IP Processor HDLC and PPP termination
Line Input Card
MT9076 Framer MT90880 TDM-IP Processor
Remote Resource Pool
MT90880 TDM-IP Processor Media Interface
IP Router
Packet
PSTN
Figure 2 - Multiservice Access Platform using the MT90880
4.2
Circuit Emulation Services
The MT9088x family can be used to transport TDM links across the packet domain and transparently reconstruct the links at the far end (Figure 3). This is similar to the circuit emulation services defined by the ATM Forum, with the MT9088x device providing the circuit emulation inter-working function. The part is capable of handling circuit emulation of both structured and unstructured DS1 (T1) and E1 links. The use of an Ethernet packet infrastructure for this facilitates the extension of TDM services between locations using easy to manage and readily available network hardware. The part supports dynamic bandwidth management, by providing the ability to add and delete timeslots from the packet stream as required. A cross-connect service can also be provided by using an Ethernet switch to route packet streams to different destinations.
21
Zarlink Semiconductor Inc.
MT90880/1/2/3
Line Input Card
T1/E1/ ISDN
Data Sheet
Line Input Card MT90880 TDM-IP Processor MT90880 TDM-IP Processor
T1/E1/ ISDN
MT9076 Framer/LIU
Ethernet
MT9076 Framer/LIU
Circuit Emulation Interworking Function transparent data flow
Circuit Emulation Interworking Function
Figure 3 - Circuit Emulation Services over the packet network
4.3
Internet Off-load
Internet off-load is a means of relieving the congestion in circuit-switching equipment caused by excessive dial-up modem traffic with long call duration. Modem traffic is directed to the packet-switched network, bypassing traditional voice switches. This reduces the capacity of the required circuit switches, and hence the cost of a typical installation. The MT90880 is an ideal device for implementing internet off-load, allowing voice traffic to be routed through the TDM switch to the voice switching infrastructure, and modem traffic to be sent over the packet network to the Remote Access Concentrator (Figure 4). The RAC could be local or remote, with traffic routed over the data networks.
Line Input Card Voice Traffic
PSTN
T1/E1/ ISDN
MT9076 Framer
TDM
MT90880 TDM-IP Processor
TDM
Class 5 Voice Switch
Modem Traffic
Ethernet
Dial-up subscribers MVTX2604 Ethernet Switch
Packet
Figure 4 - Internet Off-load solution using the MT90880
22
Zarlink Semiconductor Inc.
MT90880/1/2/3
4.4 Remote Access Concentration
Data Sheet
In a similar manner to the internet off-load solution outlined above, the MT9088x devices can also be used to route traffic to a remote resource pool. This allows resources to be centralized, with multiple line cards accessing the resource pool via the Ethernet switching fabric. A typical application for this is a remote access concentrator for dial-up modem traffic, and Figure 5 shows an example of this. The MT90880 on the line card forms the modem data into packets, which are transmitted via the Ethernet switch to a remote DSP pool. The MT90880 on the remote card converts the packets back to TDM and forwards them to the DSP pool over the TDM link. The demodulated data is then transmitted back over the packet network to the router via the MT90880. This packet-based architecture can be easily extended to support large numbers of modem calls by simply adding more Ethernet switch interfaces. The architecture can also support ISDN PPP traffic. The DSP pool strips off the HDLC framing and forwards the packets to the MT90880 for transmission over the IP packet network.
Line Input Card
PSTN
T1/E1/ ISDN
MT9076 Framer
TDM
MT90880 TDM-IP Processor
Packet
Modulated Traffic
Ethernet
MVTX2604 Ethernet Switch
Ethernet
Demodulated packet data
IP Router
Line Input Card
Remote MT9076 Modem Framer DSP Pool
TDM PCI
MT90880 TDM-IP Processor
Figure 5 - Remote Access Concentrator using the MT90880
23
Zarlink Semiconductor Inc.
MT90880/1/2/3
4.5 Local Resource Pool Example
Data Sheet
For smaller systems, the built-in TDM switch allows traffic to be switched out to a local resource pool on the line card. The provision of a high bandwidth, 33 MHz PCI interface allows the processed data to be returned to the MT90880 ready for transmission over the network (Figure 6). Alternatively, the Local TDM interface can be used to return data to the MT90880 for transmission across the packet network. The PCI interface on the MT90880 contains a DMA controller to simplify packet handling over the PCI bus. This can read packets out of the system memory on the PCI bus and place them on the appropriate queue for transmission.
Line Input Card
Examples: HDLC, modem pool, voice codecs, echo cancellers
Local Resource Pool
PCI
TDM
data flow
PSTN
T1/E1/ ISDN
MT9076 Framer
TDM
MT90880 TDM-IP Processor
Ethernet
Packet
Figure 6 - Use of a Local Resource Pool
24
Zarlink Semiconductor Inc.
MT90880/1/2/3
4.6 H.100/H.110 Extension
Data Sheet
The H.100/H.110 TDM bus commonly used in today's computer telephony systems is based on a physical backplane the width of a single telecom rack. Extending the reach of the bus is expensive using traditional TDM infrastructure. Such links are not easily scalable, and require accurate and stable clock generation. An MT9088x device enables the bus to be simply and easily extended beyond confines of the rack using an Ethernet connection over simple twisted pair cable. This enables the entire bus to be replicated in another physical location using a low cost but flexible and easily managed connection medium (see Figure 7). Figure 7 shows the MT9088x device connected to a TDM backplane via a TDM switch device (e.g. the Zarlink MT90866). This is used to concentrate the backplane onto the TDM interface of the MT9088x. The configuration allows any of the TDM channels on the original backplaneto be switched onto any channel on the extension backplane, and vice-versa.
Original H.100/H.110 bus segment Extension H.100/H.110 bus segment
MT90866 H.110 Switch
MT90880 TDM-IP Processor
Ethernet
MT90880 TDM-IP Processor
MT90866 H.110 Switch
transparent data flow
Figure 7 - H.100/H.110 Extension over Ethernet link
4.7
H.100/H.110 Expansion
One of the issues faced by medium and high-end telecommunication systems is scalability. The H.100/H.110 TDM bus is limited to 4096 concurrent timeslots, or 2048 full duplex links. The MT9088x family can be used to expand the capacity of a system by switching timeslots between multiple separate H.100/H.110 bus segments. This application is shown in Figure 8. Unlike parts based on expensive or proprietary infrastructure, the use of an Ethernet switch fabric enables common, readily available network hardware to be employed, reducing both installation and operational costs. As in Figure 7, the MT90866 TDM switch is used to concentrate the TDM backplane onto the MT9088x TDM interface. This allows any channel on a bus segment to be switched onto any channel on any other bus segment.
25
Zarlink Semiconductor Inc.
MT90880/1/2/3
H.100/H.110 bus segment H.100/H.110 bus segment H.100/H.110 bus segment
Data Sheet
MT90866 H.110 Switch
MT90880 TDM-IP Processor
MT90866 H.110 Switch
MT90880 TDM-IP Processor
MT90866 H.110 Switch
MT90880 TDM-IP Processor
Ethernet Ethernet Ethernet MVTX2604 Ethernet Switch
Figure 8 - H.100/H.110 Expansion using Ethernet Switching Fabric
5.0
5.1
Functional Operation
Overview
The MT9088x family provides the data-plane processing to enable constant bit rate TDM services to be carried over a packet network, such as an Ethernet or IP network. The device segments the TDM data into user-defined packets, and passes it transparently over the packet network to be reconstructed at the far end. This has a number of applications, including packet backplanes for TDM-based equipment, and emulation of TDM circuits (similar to the circuit emulation services for ATM, see references 5 and 6). The advantages of using a packet medium for transport and distribution of TDM services include: Scalability TDM-based systems are hard to scale in capacity for two main reasons:
* TDM clock frequency increases in proportion to the number of input channels, and this high frequency clock must be distributed around the system while maintaining accurate phase alignment * Physical limitations - the form factor of hard backplane systems effectively restrict the TDM backplane to a single rack, limiting the size of the system that can be connected
Efficiency
Service provisioning
Cost Physical distribution
TDM equipment dedicates capacity to all channels, whether in use or not. Use of a packet-based system allows the available bandwidth to be statistically multiplexed, taking advantage of the fact that not all channels are active all the time. It is easier to add new services by adding new line input cards or resource cards. These are not constrained to be in the same physical rack, as with a TDM backplane system. Network hardware is readily available at lower cost than equivalent TDM equipment, reducing the overall cost of ownership. Equipment may be physically distributed over a wider area, connected either by simple twisted pair network cable, or by fibre. This allows the footprint for co-located equipment (for example) to be small, with the main resources located elsewhere on the network.
26
Zarlink Semiconductor Inc.
MT90880/1/2/3
Transparent data flow between TDM equipment
Data Sheet
TDM equipment
constant bit rate TDM link
MT9088x TDM-Packet conversion
interworking function
packet network
MT9088x TDM-Packet conversion
interworking function
TDM equipment
constant bit rate TDM link
Figure 9 - MT9088x Family Operation The MT9088x family provides structured, synchronous TDM service, operating at the 64 Kbs channel (DS0) level. The devices exhibit the following general service characteristics: 1. N x 64 Kbs trunking of any group of timeslots into a single "virtual channel connection" or "context"; these timeslots need neither be contiguous nor from the same stream of data 2. Ability to add or delete timeslots from a context in order to support dynamic bandwidth utilization. 3. Provision of a cross-connect service (i.e. contexts coming from several MT9088x devices are capable of being terminated by a single MT9088x device at the far end). 4. Ability to operate in "master mode" (supplying the timing to the TDM interface), or in "slave mode" (receiving the timing from the TDM interface). 5. Local TDM interface, for connection of external resources, e.g. echo cancellers, modem termination, HDLC controllers 6. Low latency connection, with end to end delay of less than 0.5 ms, depending on user configuration
27
Zarlink Semiconductor Inc.
MT90880/1/2/3
5.2 Basic Operation
Data Sheet
A diagram of the MT90880 device is given in Figure 10, which shows the major data and control flows between functional components.
Local TDM Interface 32 ports at 2, 4, or 8 Mbit/s Host Control/Data Interface 32 bit, 33 MHz PCI
WAN Receive
Packet Transmit
WAN Interface & Multiplexer
Queue Manager
Dual Packet Interface MAC
WAN Transmit
Packet Receive
DPLL
Memory Manager and SSRAM Interface Controller
JTAG Test Controller
Data Flows Control Flows
Packet Memory 0.125 - 8 MBytes SSRAM (Burst or ZBT type)
JTAG Interface
Figure 10 - MT90880 Data and Control Flows
5.2.1
WAN Access Interface
The WAN Access Interface consists of up to 32 ports, each with an input an output data stream operating at 2.048 Mbs. Alternatively, it can be configured as 8 ports operating at 8.192 Mbs. All 32 ports can operate using a common clock (synchronous mode) or using an independent clock for each port (asynchronous mode). When operating synchronously, the device can either operate as a slave, accepting an external clock, or as a master, supplying the clock to the devices on the WAN Access Interface from its internal Stratum 4E DPLL. The master clock can be locked to any of the incoming 32 frame references.
5.2.1.1
TDM Packet Assembly
Data traffic received on the WAN Access Interface is sampled in the WAN Interface block. It is then forwarded either to the WAN Receive block for packet assembly, or out to the TDM switch. The switch can be used both for re-ordering timeslots before packet assembly, or to divert traffic out of the local TDM interface for processing in a local resource pool (e.g. a DSP or other data processing unit). The WAN Receive block can handle up to 128 active virtual channels or "contexts" simultaneously. A context may contain any number of timeslots, from 1 to 1024. This is known as "N x 64 Kbs" trunking. Timeslots may be added or deleted dynamically from a context to optimize network bandwidth utilization.
28
Zarlink Semiconductor Inc.
Packet Switch Fabric Interface Dual Redundant 10/100 Mbit/s MII Interfaces
1K Switch
DMA Control
PCI Interface
Admin.
WAN Access Interface 32 TDM ports at 2 or 8 Mbit/s
MT90880/1/2/3
Data Sheet
Trunking is not limited to contiguous timeslots. Each context is capable of carrying any combination of timeslots, taken from any stream. However, packets are assembled sequentially, with data placed into the packet as it arrives, maintaining timeslot and stream order.
5.2.2
Packet Transmission
Packets ready for transmission are queued to the switch fabric interface by the Queue Manager. Four classes of service are provided, allowing some packet streams to be prioritized over others. For example, to keep the latency of the TDM traffic low, TDM contexts can be prioritized over traffic from the CPU. Similarly, context control traffic can in turn be prioritized over maintenance traffic. Two types of prioritization are allowed: weighted fair queuing, where a traffic class is allocated a fixed proportion of the bandwidth, and strict priority, where all higher priority traffic is sent before any lower priority traffic. On transmission, the Packet Transmitter appends a packet header, which has been set up in advance by the control processor. This allows the higher level protocols to be user-defined. The header is entirely user programmable, allowing any protocol to be used provided that the field contents remain static (i.e. do not change from packet to packet). Supported protocols include Ethernet, VLAN, IPv4, UDP (without using the checksum) and CDP (Zarlink's "Context Descriptor Protocol" on page 36).
5.2.3
CPU Packet Generation
The control processor can generate packets directly, allowing it to use the network for out-of-band communications. This can be used for out-of-band transmission of control data or network setup information, e.g., routing information. The PCI interface can also be used by a local resource for network transmission of processed data. Each of these types of traffic can be allocated a different class of service, allowing the bandwidth of the link to be carefully managed. A DMA controller is built into the PCI interface to allow pre-formatted packets to be read directly from PCI memory and queued to the appropriate packet interface.
5.2.4
Packet Reception
Incoming data traffic on the packet interface is received by the MACs, which determines if the packets are intended for the device. If they are, the packets are forwarded to a packet classifier to determine the destination. This can either be the TDM domain (either WAN or Local interfaces) or the PCI interface. WAN traffic is then further classified to determine the context it is intended for. Each TDM context has an individual queue, and the TDM re-formatting process re-creates the TDM streams from the incoming packet streams. Upon context setup, the TDM output is delayed by a programmable number of TDM frames, creating a jitter buffer. This is required to smooth out the variation in delay between individual packets. There are four separate queues to the PCI interface, allowing different traffic flows to be classified separately. For instance control information could be directed to one queue, with traffic for a local resource pool directed to another queue. This simplifies access to the device by multiple resources or applications. Again the DMA controller can be used to retrieve packet data and write it out into external system memory on the PCI bus.
5.2.5
Call Setup and Control
Context setup must be negotiated between transmitting and receiving devices. This is handled by out-of-band signalling between the control processors at each end. Once the context has been established, the first data packet is transmitted. Each data packet contains a field in the header identifying the context to which it applies. This allows the receiving end to decode the packet and forward the data to the correct TDM channels. Context modification (e.g., addition or deletion of timeslots) must also be set up in advance before the actual modification takes place. Changes are signalled out of band by the transmit end, which waits for confirmation from the receive end. This indicates that the amendments have been made, and it is ready to handle modified
29
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
packets. Once confirmation has been received, the changes are activated at the transmit end. A synchronization flag in the header marks the first modified packet. This tells the receiver to switch over to the amended context information. Removal of a context is signalled in the same way, with an acknowledgement from the receiver. Following "tear-down", the internal queues are cleared, and any packets received for that context are discarded.
5.3
Data and Control Flows
The major data flows within the device are as follows: 1. WAN Access Interface to Packet Interface 2. Packet Interface to WAN Access Interface 3. WAN Access Interface to Packet Interface via a Local Resource Pool 4. Packet Interface to WAN Access Interface via a Local Resource Pool 5. PCI Interface to Packet Interface 6. Packet Interface to PCI Interface
WAN Access Interface to Packet Interface
Data traffic received on the WAN interface is divided into packets by the WAN Receiver. The packets are stored in the external packet memory. A pointer to the packet is passed to the queue manager, which appends completed packets to the appropriate transmission queue. On transmission the packet is retrieved from memory by the Packet Formatter, a pre-defined header added, and then passed to the MAC for transmission.
Local TDM Interface
Host Interface
WAN Access Interface
Packet Interface
Packet Memory
Figure 11 - WAN to Packet Data and Control Flow
Data Flow Control Flow
30
Zarlink Semiconductor Inc.
MT90880/1/2/3
Packet Interface to WAN Access Interface
Data Sheet
Incoming data is received by the MAC, and its destination address is checked. Packets intended for this device are passed to the packet receive block for placing in external memory, while the header is classified to determine the appropriate destination. A pointer to the packet is passed to the queue manager to be placed on the correct queue as indicated by the classification result. The WAN Transmit block retrieves the data from packet memory, and directs it towards the appropriate timeslots on the WAN interface.
Local TDM Interface
Host Interface
WAN Access Interface
Packet Interface
Packet Memory
Figure 12 - Packet to WAN Data Flow
Data Flow Control Flow
31
Zarlink Semiconductor Inc.
MT90880/1/2/3
WAN Access Interface to Packet Interface via a Local Resource Pool
Data Sheet
Data traffic received on the WAN interface is diverted to the TDM switch and out of the local TDM interface for processing in a local resource pool (e.g., a DSP or other data processing unit). The processed data can re-enter the device in two ways. Where the data is still constant bit rate, it can re-enter the device through the local TDM interface, and be routed by the TDM switch to the WAN Receive block for packetisation. Alternatively, if the processed data has been converted to a variable bit rate or packet format, it can be moved into the device as through the PCI bus using the DMA controller to automatically fetch packets from system memory. The Queue manager appends the packets to the appropriate transmission queue. On transmission the packet is retrieved from memory and passed to the MAC for transmission.
Local Resource Pool e.g. DSP pool
WAN Access Interface
Packet Interface
Packet Memory
Figure 13 - WAN to Packet Data Flow via Local Resource
Data Flow Control Flow
Packet Interface to WAN Access Interface via a Local Resource Pool
Incoming data is received by the MAC, and its destination address is checked. Packets intended for this device are passed to the packet receive block for placing in external memory, while the header is classified to determine the appropriate destination. A pointer to the packet is passed to the queue manager to be placed on the correct queue as indicated by the classification result. If the destination is the PCI interface, the DMA controller is used to write the packets directly into system memory. After local processing, the data is re-directed to the WAN interface by going through the Local TDM interface and the TDM switch.
32
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Local Resource Pool e.g. DSP pool
WAN Access Interface
Packet Interface
Packet Memory
Figure 14 - Packet to WAN Data Flow via Local Resource
Data Flow Control Flow
PCI Interface to Packet Interface
The host CPU or other devices can use the MT9088x device to send data via the packet network. The data to be sent is formatted into packets with the appropriate protocols in system memory. The DMA controller in the MT9088x is programmed to fetch this information, and place it into the appropriate packet queue. On transmission the packet is retrieved from memory by the Packet Formatter in the normal way, and passed to the MAC for transmission.
Host Processor
WAN Access Interface
Packet Interface
Packet Memory
Figure 15 - PCI to Packet Data Flow
Data Flow Control Flow
33
Zarlink Semiconductor Inc.
MT90880/1/2/3
Packet Interface to PCI Interface
Data Sheet
Similarly, packets destined for the host CPU or other PCI devices can be sent over the packet network to the PCI device. The headers of incoming packets are parsed by the Packet Classifier, and can be directed to one of four queues pointing towards the PCI interface. The classifier can be set-up so that each queue is dedicated to a specific device or application flow.
Host Processor
WAN Access Interface
Packet Interface
Packet Memory
Figure 16 - Packet to PCI Data Flow
Data Flow Control Flow
5.4
Packet Assembly
The incoming TDM data streams are assembled into packet payloads by the WAN Receive block. This can handle up to 128 active contexts at a time, where each context represents a "virtual channel connection" in CES terms. Each context generates a single stream of packets, identified by a label in the packet header known as the "context ID". A context may contain any number of 64 Kbs channels. These channels need not be contiguous, and in synchronous mode they can be selected from any input stream. In asynchronous mode each stream is independently clocked, which can result in phase and frequency differences between streams. Therefore, in this mode contexts may only contain channels from a single stream. Channels may be added or deleted dynamically from a context. This feature can be used to optimize bandwidth utilization. Modifications to the context are synchronized with the start of a new packet.
5.4.1
Payload Order
Packets are assembled sequentially, with each channel placed into the packet as it arrives at the WAN Access Interface. A fixed order of streams and channels is maintained (see Figure 17), with channel 0, stream 0 placed before channel 0, stream 1, which is placed before channel 1, stream 0. It is this order that allows the packet to be correctly disassembled at the far end.
34
Zarlink Semiconductor Inc.
MT90880/1/2/3
Stream 0 Stream 1 Stream 2 Channel 0 Channel 0 Channel 0 Channel 1 Channel 1 Channel 1 Channel 2 Channel 2 Channel 2 Channel 31 Channel 31 Channel 31
Data Sheet
Stream 31
Channel 0
Channel 1
Channel 2
Channel 31
Figure 17 - Channel and stream order for packet formation
Each packet contains one or more complete TDM frames of data, in sequential order. This groups all the channels for the first frame, followed by the same set of channels for the subsequent frame, and so on. Partial TDM frames are not permitted, and each packet starts at the beginning of a new frame. Figure 18 shows the structure of a packet containing x 64 Kbs channels, and n TDM frames.
5.4.2
Packet Structure
The fixed header at the start of each packet is added by the Packet Transmit block. This consists of up to 64 bytes, containing the Ethernet header, any upper layer protocol headers, and the two byte context descriptor field (see section below). The header is entirely user programmable, enabling the use of any protocol provided there are no dynamic fields (i.e. fields that change from packet to packet). The Packet Transmit block also maintains a "shadow" header for each context. This is used for context modification, for example addition of deletion of channels. Any header changes required by a context modification are programmed into the shadow header in advance. When the changes are complete, the "shadow" header is swapped with the existing header for the first packet containing the new context payload.
Packet Size
The payload and header size must be chosen such that the overall packet size is not less than the Ethernet standard minimum packet size of 64 bytes. Where this is likely to be the case, the header must be padded (as shown in Figure 18) to ensure that the packet is large enough. The padding is required in front of the TDM payload, to ensure that the WAN Transmit block reads packets correctly on reception. This block is given a pointer to the start of the TDM payload, and then continues to read data until the end of the packet, as indicated by the packet length. In applications where large payloads are being used, the payload size must be chosen such that the overall packet size does not exceed the maximum Ethernet packet size of 1518 bytes (1522 bytes with VLAN tags).
35
Zarlink Semiconductor Inc.
MT90880/1/2/3
Ethernet Header Upper Layers (optional) Context Descriptor Static Padding (if required) Channel 1 Channel 2
Data Sheet
Fixed Header
Data for TDM Frame 1
Channel x Channel 1 Channel 2 Channel x
Data for TDM Frame 2
Ethernet Payload 46 to 1500 bytes
Data for TDM Frame n
Channel 1 Channel 2 Channel x Ethernet FCS
Figure 18 - Packet Structure for MT9088x Family
5.4.3
Context Descriptor Protocol
The MT9088x family uses a two-byte field within the packet header to convey which context the packet belongs to. The format of the field is as follows:
Ver. C S
15 12
Context ID
87 0
Figure 19 - Context Descriptor Field
Field definitions
Context ID A unique number identifying the context to the receiving device. The Context ID is assigned by the receiving device during context establishment. The MT9088x only supports values in the range 0-127, and hence bits 7-11 must be set to zero. CS Context Switch Bit. This bit toggles when there is a change to the context, e.g., addition or deletion of new timeslots from the packet. The toggle action ensures that the change to the context is still signalled even if the first packet indicating the change is lost. Protocol version number. For the MT9088x family, the version number is always zero.
Ver
5.5 5.5.1
Context Negotiation and Establishment Overview
The establishment of a context to carry TDM data across a packet network is a negotiated process. The call parameters (e.g. the context ID label, number of channels to be included, number of frames) must be agreed between the host CPU's at either end of the packet network. Similarly, subsequent changes to a context must also
36
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
be agreed and synchronized between the two ends. The remote end is signalled to expect a modified context, and its host sets up the new context information. This new setup is activated on receipt of the first packet containing the new channel configuration. This section describes the negotiation process that takes place at context establishment and modification. The examples assume two MT9088x devices connected via a packet network. One device, the Packet Transmit End, receives bytes from the WAN, assembles them into packets and transmits them over the network. The second device, the Packet Receive End, receives packets from the network, deconstructs them into bytes and transmits them in their proper timeslots toward the destination. Each MT9088x device has its own host, denoted "PTX Host" and "PRX Host". The tables describe the process of context negotiation, rather than the protocol. The actual protocol can be chosen to suit the overall application and customer requirements.
5.5.2
New Context Establishment
Table 15 describes the process for setting up a new context.
Packet Transmit End (PTX) Packet Receive End (PRX)
1
2
PTX Host sets up a new transmit context, assigning a local context ID. This local context ID is used to identify the context within the packet transmit device. PTX Host signals Packet Receive host to expect a new context, with details of the channels involved and the destination channels. PRX Host sets up new receive context, assigning a local context ID (this may not be the same as the PTX's transmit context ID). PRX host sends an acknowledgement back to the PTX that the context is set up and ready to receive packets.The PRX acknowledgement includes the local receive context ID. PTX host completes context setup by placing the PRX receive context ID into the packet header. PTX host activates new context. At the start of the next TDM frame, the MT9088x commences formation of the first packet for the new context. This packet is prepended with the new packet header. First packet received for the new context, identified by the context ID label. Upon reception of packet the MT9088x waits for a predetermined number of TDM frames to allow for delay variation in the LAN, then automatically activates new context. The value of the context switch bit is recorded for reference.
Table 15 - New Context Establishment
3
4
5 6 7
8
37
Zarlink Semiconductor Inc.
MT90880/1/2/3
5.5.3 Context Modification (Addition or deletion of physical channels)
Data Sheet
Context modification must be an atomic operation. Therefore, if the host modifies the context setup, it must wait until that change has been carried out before attempting further modifications. This will take a bounded but indeterminate time, since the context will not actually be modified until the start of the next new packet. The context state machine will set a flag to indicate to the host that it is in the process of modifying the context, and that the host should refrain from further updates. However, distinct contexts can be modified simultaneously, since each context is completely independent from any other. As a consequence, the MT9088x family supports a cross-connect service, where each context (or virtual channel) can be sent over the packet network to a different terminating device. The context modification process is shown in Table 4.
Packet Transmit End (PTX) Packet Receive End (PRX)
1 2
PTX Host modifies an existing context to add or delete channels. PTX Host signals Packet Receive host to expect a modified context, with details of the channels to be added or deleted, and their destination channels. PRX Host modifies receive context concerned. PRX host sends an acknowledgement back to the PTX that the context has been modified and is ready to receive packets. PTX host activates the previously programmed context change. At the start of the next new packet, the MT9088x commences formation of the first packet for the modified context. This packet is prepended with the new packet header, with the context switch bit toggled. First packet received for the modified context, identified by the toggling of the context switch bit. This automatically activates the previously programmed context modifications. The new value of the context switch bit is recorded for reference.
Table 16 - Context Modification Process
3 4
5 6
7
38
Zarlink Semiconductor Inc.
MT90880/1/2/3
5.5.4 Context Removal
Data Sheet
Context removal is required when all active channels are removed from a context. Normally, channel deletion is signalled in the first packet of the modified context. However, when the last channel is deleted from a context, no packet will be transmitted since there is no payload. Therefore the receiver will not be signalled that the channel deletion has taken place, and the context will underrun, waiting for further packets to arrive. Therefore, it is not permitted to tear down a context simply by deleting all of its contents. Table 5 below describes the context removal procedure, known as "context teardown", used to allow contexts to be deleted cleanly.
Packet Transmit End (PTX) Packet Receive End (PRX)
1 2 3 4 5
PTX Host signals PRX Host to expect a context removal or "teardown" PRX Host programs MT9088x device to expect a context teardown. PRX Host sends an acknowledgement back to the PTX Host. PTX host activates the context teardown. The next new packet is the last one to be transmitted for this context. The context switch bit in the header is toggled to signal the context removal. Last packet received for the context to be removed, identified by the toggling of the context switch bit. This automatically activates the previously programmed context teardown. The PRX Queue manager discards any future packets that arrive with the same context ID.
Table 17 - Context Teardown Process
6
7
5.5.5
Context Cleardown
A second means of context removal, known as "context cleardown", is provided for situations where a system error has occurred, and the context has not been removed properly. The cleardown mechanism prevents expired contexts from using up system resources and memory. For example, during context teardown, if the last packet sent by the PTX is not received by the PRX, the context will still exist at the PRX when it has already been deleted by the PTX. In this situation, a timeout informs the PRX Host that the context teardown notified by the PTX Host has not taken place. The PRX host then needs to take two actions: 1. Instruct the queue manager to flush the queue of packets for this context. Following this, the queue manager will discard any packets that arrive using the same context identifier. 2. Program a context cleardown, which immediately clears any state associated with the context.
39
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.0
6.1
Data Sheet
Functional Block Descriptions
WAN Interface and Multiplexers
The WAN Interface provides the synchronization between the external TDM streams and the internal logic. It also multiplexes the between the cross-connect switch and two TDM processing blocks. The multiplexing allows the switch to be used both for routing data to the local TDM interface and for re-ordering timeslots on the way in and out of the device. Features include: * * * * * * * * 32 bi-directional TDM ports, providing 1024 full-duplex channels Data rate of 2.048 Mbs supported over all 32 ports Data rate of 8.192 Mbs supported over 8 ports (MT90880 and MT90881 only) Supports "generic E1" mode, where 2.048 Mbs TDM streams are supported using a 2.048 MHz clock Individual per port control over the polarity of the frame pulse and clock Individual per channel high impedance output control The primary and secondary references can be selected from any of the incoming 32 ports (8 ports in 8 Mbs mode) Three operational modes: * * *
Synchronous master - the MT9088x provides a common clock and frame pulse to all ports, which may be locked to an incoming frame reference Synchronous slave - the MT9088x accepts a common external clock and frame pulse to be used by all ports Asynchronous mode - Each port has its own clock and frame pulse input
6.1.1
Port Data Formats
As listed above, the MT9088x family accepts three data formats. A brief summary of the characteristics of these formats is given in Table 6 below. For more information see the ST-BUS specification (reference 7). The overall data format is set for the entire WAN Interface device, rather than on a per port basis. However, there is individual per port control of the polarity of both the incoming clock and frame pulse. There is also control of polarity of the master clock and frame pulse outputs, independent of the chosen data format (used when operating in synchronous master mode).
Number of channels per frame Clock Frequenc y Nominal Frame Pulse Width Frame Pulse Polarity Frame Boundary Alignment
clock
Data Format
Data Rate
frame pulse
Generic E1 ST-bus ST-bus
2.048 Mbs 2.048 Mbs 8.192 Mbs
('80, '81 only)
32
(streams 0-31)
2.048 MHz 4.096 MHz 16.384 MHz
488 ns 244 ns 61 ns
Per port control Per port control Per port control
Per port control Per port control Per port control
Starts at boundary Straddles boundary Straddles boundary
32
(streams 0-31)
128
(streams 0-7)
Table 18 - Input Data Formats accepted by the MT9088x family
All WAN Interface inputs (including data in, clocks and frame pulses) have internal pull-down resistors, therefore they can be safely left unconnected if not used.
40
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.1.2 Operational Modes
Data Sheet
The WAN Interface operates in three distinct modes: synchronous master, synchronous slave and asynchronous mode.
Synchronous Master Mode
In synchronous master mode, the MT9088x supplies the clock and frame signals to the external WAN infrastructure (e.g. framers or TDM backplane). The internal Stratum 4E DPLL is used to lock onto a primary reference signal. This can be chosen from any one of the 32 incoming frame references. A secondary reference may also be selected, and this is automatically switched in if the primary reference fails. The clock and frame pulse generated by the DPLL are used as the master timing source to the WAN Access Interface, and to clock in and out data on all 32 ports. Typically, this configuration will be used to connect to framers. The MT9088x can be set to choose a primary and secondary frame reference from any of the 32 ports. The internal DPLL is used to lock onto the chosen reference, and provide a stable, low-jitter master clock to drive the TDM data buses between the framers and the MT9088x device. An example of this is shown in Figure 20. An MT90880 is shown connected to up to 32 MT9076 T1/E1 framer/LIU devices, using the ST-bus at 2.048 Mbs. Each framer generates a frame pulse when a frame boundary is detected on the line, and this is fed into the MT90880 via the WAN interface's frame inputs WAN_FRMI[x]. One of these is selected as a reference for the internal DPLL, which generates the 4.096 MHz clock and the frame pulse required for the ST-bus operation. This is used both to clock data in and out of both the framer and the MT90880. The clki[31:0] inputs should be left unconnected, as shown in the figure below.
41
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
MT9076 DO Combined DI Framer-LIU
T1 or E1 line RxFP C4b F0b 8 KHz
WAN_STI0 WAN_STO0 WAN_CLKI0 WAN_FRMI0
MT90880 TDM-IP Processor
MT9076 DO Combined DI Framer-LIU
T1 or E1 line RxFP C4b F0b 8 KHz
WAN_STI1 WAN_STO1 WAN_CLKI1 WAN_FRMI1
MT9076 DO Combined DI Framer-LIU
T1 or E1 line RxFP C4b F0b 8 KHz
WAN_STI31 WAN_STO31 WAN_CLKI31 WAN_FRMI31 internally used TDM clock and frame
MUX
DPLL
Master Clock Output ST-Bus 2.048Mbit/s mode 4.096 MHz 8 KHz
WAN_CLKO WAN_FRMO
Figure 20 - Connecting to Framers in Synchronous Master Mode
The MT90880 may also be used as a TDM backplane master, such as an H.100/H.110 bus (reference 8), or an H-MVIP backplane (reference 9). The integrated DPLL provides a very stable, low jitter timing reference suitable for use as the master timing source for a backplane, with automatic, low MTIE failover from primary to secondary reference in the event of a reference failure.
Synchronous Slave Mode
In synchronous slave mode, the MT9088x accepts a clock from the WAN, rather than mastering the clock. One of the 32 incoming ports is chosen to provide the primary timing reference, and its clock and frame pulse are used directly to clock the data in and out on all 32 streams, bypassing the DPLL output. Again, a secondary reference port may be chosen, and this is automatically switched in if the primary fails. Unused clock and frame inputs may be left unconnected, as all inputs are connected to an internal 100 K pull-down resistor to prevent them from floating. A typical application for this configuration is to connect to a TDM backplane, where the MT9088x is used as a backplane slave device. An example of this is Figure 21, which shows an MT90880 connected as a backplane slave to an H.100/H.110 TDM backplane (reference 8). An MT90866 TDM switch device is shown interfacing the MT90880 to the backplane. Up to three MT90880 devices could be connected directly to a single MT90866 switch. The CT_C8_A and CT_C8_B backplane clocks are used as the primary and secondary master clocks to
42
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
the slave devices. The MT9088x family can also be connected as slave devices to older TDM backplanes such as MVIP and H-MVIP buses (reference 9), either directly or through a TDM switch. In synchronous slave mode although the DPLL is not used to sample data from the WAN TDM ports, it is still used to provide the clocks required by the internal TDM switch. The device is able to tolerate jitter on the primary and secondary reference clocks in excess of the G.823 and G.824 standards (references 11 and 12) when the WAN TDM ports are run at 2.048 Mbs data rate.
CT_STio0
STio0
MT90866 H.100/H.110 TDM Switch
STo0 STi0 STo1 STi1
WAN_STI0 WAN_STO0 WAN_STI1 WAN_STO1
MT90880 TDM-IP Processor
CT_STio1
STio1
CT_STio31
STio31
STi7 STo7
WAN_STI7 WAN_STO7
H.100 / H.110 backplane
CT_C8_A /CT_FRAME_A 8.192 MHz 8.192 MHz C8_A_io FRAME_A_io ST_CKo0 ST_FPo0
16.384 MHz
16.384 MHz
WAN_CLKI0 WAN_FRMI0 internal TDM clock and frame
CT_C8_B /CT_FRAME_B
C8_B_io FRAME_B_io
ST_CKo1 ST_FPo1
WAN_CLKI1 WAN_FRMI1
WAN_CLKI2 WAN_FRMI2
WAN_CLKI31 WAN_FRMI31
MUX
WAN_CLKO
DPLL
Slave Mode Bypass ST-bus 8.192Mbit/s mode
WAN_FRMO
Figure 21 - Connecting to an H.100/H.110 Backplane in Synchronous Slave Mode
43
Zarlink Semiconductor Inc.
MT90880/1/2/3
Asynchronous Mode
Data Sheet
In asynchronous mode, each port uses its own clock to sample and drive the data streams. Since each clock can be at a slightly different frequency, trunking of timeslots is restricted to be within the same stream. The TDM cross-connect switch cannot be used in asynchronous mode. The diagram in Figure 22 shows how the device might be connected to T1/E1 framers in asynchronous mode. Each incoming line is independently timed, bypassing the DPLL in the MT9088x device. The MT9076 contains an integrated PLL to multiply up the line rate to the 4.096 MHz ST-bus clock.
MT9076 DO Combined DI Framer-LIU
T1 or E1 line C4b F0b 4.096 MHz 8 KHz
WAN_STI0 WAN_STO0
MT90880 TDM-IP Processor
WAN_CLKI0 WAN_FRMI0
MT9076 DO Combined DI Framer-LIU
T1 or E1 line 4.096 MHz C4b F0b 8 KHz
WAN_STI1 WAN_STO1
WAN_CLKI1 WAN_FRMI1
MT9076 DO Combined DI Framer-LIU
T1 or E1 line C4b F0b 4.096 MHz 8 KHz
WAN_STI31 WAN_STO31
WAN_CLKI31 WAN_FRMI31
MUX
WAN_CLKO
DPLL
Bypassed in Async. mode WAN_FRMO
Figure 22 - Connecting Framers to the MT90880 in Asynchronous Mode
44
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.2 TDM Cross-Connect Switch
Data Sheet
The TDM switch is a non-blocking switch with 1024 bi-directional channels. It can be used both for routing WAN traffic out to the local TDM interface, and for re-ordering timeslots on the way in or out of the device. Internally, it provides four independent data directions, from WAN side to local side, local to WAN, WAN to WAN and local to local. A multiplexing arrangement (see Figure 23) controls the access to the TDM switch, permitting the following data flows through the device: * * * * * * * * * * * * WAN interface to Packet Interface direct (without going through the switch) Packet Interface to WAN interface direct (without going through the switch) WAN interface to Packet Interface via the TDM switch (e.g., for re-ordering timeslots on input) Packet Interface to WAN interface via the TDM switch (e.g., for re-ordering timeslots on output) WAN interface to Local interface, via the TDM switch Local interface to WAN interface, via the TDM switch Local interface to Packet Interface, via the TDM switch Packet Interface to Local interface, via the TDM switch The following flows are also possible, facilitating test modes in the system WAN interface to WAN interface, looped back through the TDM switch Local interface to Local interface, looped back through the TDM switch Packet Interface to Packet Interface, looped back through the TDM switch
Local TDM Interface MT9088x
1K x 1K switch
WAN Receive
WAN Access Interface
WAN Transmit
To Packet Interface
Figure 23 - TDM Switch Access Multiplexers
Features include: * * * * * * * Fully bi-directional, 1,024-channel x 1,024-channel non-blocking switch Accepts data rates of 2.048 Mbs, or 8.192 Mbs on the WAN interface side Accepts data rates of 2.048 Mbs, 4.096 Mbs or 8.192 Mbs on the local interface side Rate conversion between WAN and local streams Per-stream bit delay for the local input streams Per-stream bit advancement for the local output streams Per-channel constant throughput delay
45
Zarlink Semiconductor Inc.
MT90880/1/2/3
* * * * * Per-channel high impedance output control for local and WAN streams Per-channel message mode for local and WAN output streams PRBS pattern generation and testing Block memory programming for fast device initialisation Channel duplication facility for broadcast and conference applications
Data Sheet
6.2.1
Multiplexing and Blocking
Although the switch unit itself is non-blocking, care must be taken with the multiplexing arrangement, since it is possible to set up a blocking configuration outside of the switch. This is because there are two paths at each multiplexer, so when one path has been used for a given timeslot, the other path is blocked. It is also possible to block the output from the switch to a given output timeslot on the WAN side of the switch. For example, consider the following flow from WAN Access Interface to the Packet Interface, re-ordering using the switch. The input to the WAN Access Interface at stream 0 channel 0 enters the switch, and is re-mapped onto stream 1 channel 0 before entering the WAN Receive block. This ties up the following resources: * Switch input mux. at stream 0, channel 0 prevents the WAN transmit output on stream 0, channel 0 being routed via the switch (e.g., for re-ordering or directing to the Local interface. prevents the direct connection of WAN Access Interface stream 1, channel 0 to WAN Receive block. prevents any connection from the Local interface to stream 1, channel 0 on the WAN Access Interface.
* *
WAN Receive input mux. at stream 1, channel 0 Switch output for stream 1, channel 0
Similar considerations apply to other routes through the device. In general, restricting the use of re-ordering to use either on input to or output from the device reduces the potential for blocking. Similarly, loopback from WAN to WAN also sets up significant blocking potential (two muxes and the switch output), and should be avoided in normal operation where possible.
6.2.2
Re-ordering Timeslots
One application of the TDM switch is to re-order channels either on the input or output of the device. This may sometimes be necessary to provide a completely flexible channel mapping, since the packet assembly/disassembly process cannot vary the order of channels within a context. Hence a channel arriving at the packet assembly before another will always exit the packet disassembly process at the receiving end before the second channel. Where it is required to map the channels differently, the TDM switch can be used to handle the re-ordering. For example, consider the following channel mappings: * Stream 0, channel 0 is mapped to stream 0, channel 1 * Stream 0, channel 1 is mapped to stream 0, channel 0 Although individually channels can be mapped to any other channel at the packet receive end, if both these channels are contained in the same context, the packet assembly/disassembly process cannot provide this mapping, since the order of channels is changed. Therefore there are three options to obtain the desired mapping: 1. use two separate contexts for the two channels 2. re-order the channels on input using the switch 3. re-order the channels on output using the switch
46
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Use of a separate context may not be acceptable, since the number of contexts on the MT9088x family is limited to 128. Therefore the only option is to use the switch to re-order the channels. As described above, it is best to choose up front whether to re-order channels on the input or output side, to avoid potential blocking conditions in the multiplexed paths. It should also be noted that channels routed via the switch (e.g., for re-ordering) incur a three-frame delay for the switch operation. This is not the case for channels routed directly (e.g., WAN Access Interface to WAN Receive block), which incur no delay. This may be a consideration for applications where end to end latency is an issue.
6.2.3
Channel Broadcast
The switch can also be used to broadcast a single input channel to multiple output channels. This is achieved by programming the connection memory to map multiple output channels to the same input channel. Care must be taken when using this feature, since it does create blocking both within the switch itself, and through the multiplexing arrangement. This is because the number of available output channels is effectively reduced, meaning that not all input channels to the switch will be able to be mapped to an output. Similarly, the output multiplexer to the WAN Access Interface will be assigned to multiple broadcast channels, blocking those channels for output paths from the WAN Transmit block.
6.3
WAN Receive and Transmit Functions
The payload assembly process creates programmable length packet payloads from the TDM input streams. The assembly process is extremely flexible; packets can contain any number of 64 Kbs timeslots. These channels need not be contiguous, and in synchronous mode they can be selected from any input port. In asynchronous mode each stream is independently clocked, which can result in phase and frequency differences between streams. Therefore, in this mode payloads may only contain timeslots from a single port. Payloads may contain any integer number of TDM frames. The structure of a packet is shown in Figure 18, "Packet Structure for MT9088x Family," on page 36. Each stream of packets created by the packet assembler is known as a context. The packet assembler is capable of handling up to 128 different contexts simultaneously. Each context is allocated an identifier that is agreed in advance between the transmitting and receiving device, and this identifier is placed in each packet header to indicate the contents of the packet. Timeslots can be dynamically added to or deleted from a context. This helps to conserve bandwidth on the packet network, by only transmitting the active timeslots. Context modifications must be indicated in advance to the receiving end, and acknowledged before the change can be implemented, in order to allow the TDM data to be correctly re-constructed. At the receiving end of the packet network, the original TDM data must be re-constructed from the packets received. This is known as re-formatting, and follows the reverse process. A programmable jitter buffer is provided to iron out the packet delay variation across the network. The size of the jitter buffer can be programmed in units of TDM frames (i.e., steps of 125 s). Features include: * * * * * * * * Supports up to 128 simultaneous packet streams or "contexts". Each context can handle any combination of timeslots, from any TDM stream. Supports dynamic addition and deletion of timeslots. Maintains timeslot order and TDM frame within each context. Supports circuit emulation of structured T1 or E1 services. Programmable number of TDM frames per packet. Supports payload sizes from 1 to 1500 bytes. Allows a user-defined static header to be attached to each packet.
47
Zarlink Semiconductor Inc.
MT90880/1/2/3
* Programmable size jitter buffer size
Data Sheet
6.4
Operation of the WAN Receive Block
The diagram in Figure 24 shows a simplified, conceptual diagram of the WAN Receive Controller, demonstrating the principles of its operation.
Context control state machine circulating timeslot pointer context lookup table context memory data cache
Context ID
context control state cache address
cache buffer
timeslot data
to external packet memory
to memory manager
Figure 24 - Operation of the WAN Receive Controller
The WAN Receive controller receives constant bit rate TDM traffic from the WAN Interface. This interface continually presents new timeslot data at the input, together with an indication of the timeslot and stream the data is taken from. The timeslot pointer is used to look up the identity of the context that the timeslot is assigned to in the context lookup table. This table is programmed by the use to contain the mapping of timeslots into contexts. The context ID is then used to look up information about the context from the context memory. This includes a pointer to the data cache where the timeslot data for the context is assembled prior to being stored in the external packet memory. The context memory also includes a number of user programmable fields controlling the context operation, such as packet payload length, context update and context teardown. The context control state machine controls the allocation of the data cache and other information related to the context. It also handles the writing of the data cache contents into the external packet memory, requesting memory access from the Memory Management Unit. The WAN Transmit Controller functions in a similar manner, but with the data flow in reverse. The control flow remains driven by the constant bit rate of the WAN Interface.
6.4.1
Context Control in the WAN Receive/Transmit Controllers
The Context Look-Up Table is the key to the control of contexts in both the WAN Receive and WAN Transmit Controllers. This contains the mapping of individual channels into contexts, and also provides the capability to program modifications to contexts without affecting existing channels. The fields within the context lookup table are shown in Figure 25.
48
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
NFNV F V
31 24 23 19 16 15 76
Context ID
0
Figure 25 - Context Look-Up Table
Context Look-Up Table field definitions
Context ID V NV F NF The identity of the context that the channel is a member of. Value is in the range 0-127.
Valid Channel bit. A '1' indicates that the channel is an active member of the context, and to be included in the packet payload. A '0' indicates that the channel is inactive. New Valid Channel bit. A '1' indicates that the channel will become active in the next context update. A '0' indicates that the channel will be removed in the next context update. First Channel bit. A '1' indicates that this is the first channel of the indicated context (as indicated by the sequence shown in Figure 17). Each context has one and only one "first channel". New First Channel bit. A '1' indicates that this will become the first channel of the indicated context at the next context update.
Context Setup
To setup a new context, the context lookup table is programmed to enter the new context ID against all the members of the context. The New Valid Channel bit is set for all members, and the New First Channel bit is set to indicate the first channel in the sequence. The Valid Channel and First Channel bits are cleared. When context setup is complete, the Update bit in the Context Memory is set. This bit initiates the operation of the context. The timeslot pointer cycles round until it finds the first channel of the given context. At this point the state machine copies the New Valid Channel and New First Channel bits across into the Valid Channel and First Channel bits. The timeslot data is read and placed into the data cache. Each time the timeslot pointer finds more channels that are valid members of the context, the bits are copied across in the same way, and the data read into the cache. When the pointer has circulated back round to the first channel, the context setup is complete, and the Update bit in context memory is cleared. The first channel bit is required because the CPU cannot exactly time the programming of the Update bit to the start of a frame. Therefore, the first channel bit is used as a marker to indicate that this is the first channel in the context, following a frame boundary. This provides the necessary synchronisation to the start of a frame. Note that context setup is not an isolated operation, and will normally need to be co-ordinated between the WAN Receiver and the remote WAN Transmit Controller. The sequence for co-ordinating context setup is shown in Table 15 on page 37. In general, the application should ensure that the receiving context in the WAN Transmit Controller is updated and ready to receive the packets prior to setting the update bit in the WAN Receiver.
Context Modification
The WAN Receive Controller supports dynamic addition and deletion of channels into contexts without interruption to the existing channels within that context. This is achieved by use of the New Valid Channel and New First Channel bits to program the alteration in advance of the actual update where the changes take place. This allows the CPU time to setup the changes and inform the receiving device before actually initiating the modification. Note that such changes will normally need to be applied at both the local WAN Receiver and the remote WAN Transmit Controller, and that it is necessary to observe the correct sequence order to avoid mis-operation (see Table 16 on page 38). The application should ensure that following the lookup table modifications, the receiving
49
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
context in the remote WAN Transmit Controller is updated and ready to receive the modified packets prior to applying the changes to the local WAN Receiver. To add new channels to an existing context, the context lookup table is programmed to enter the context ID against all the new members of the context. As with context setup, the New Valid Channel bit is set for all new members, and the New First Channel bit is set to indicate the first channel in the sequence (if this is to change). The Valid Channel and First Channel bits are cleared. Similarly, to delete channels from a context, the New Valid Channel bit (and New First Channel bit if this was the original first channel) is cleared. For these channels the Valid Channel and First Channel bits are left alone. When the programming of the context modification is complete, the Update bit in the Context Memory is set. This bit initiates the actual modification of the context. On completion of the current packet formation the update cycle starts. The timeslot pointer cycles round until it finds the first channel of the given context. At this point the state machine copies the New Valid Channel and New First Channel bits across into the Valid Channel and First Channel bits. The timeslot data is read and placed into the data cache. Each time the timeslot pointer finds more channels that are valid members of the context, the bits are copied across in the same way, and the data read into the cache. When the pointer has circulated back round to the first channel, the context setup is complete, and the Update bit in context memory is cleared. The result at the end of the cycle is that all new channels, as indicated by the New Valid Channel bit are now valid members of the context, and that all channels where the New Valid Channel bit was cleared have now been deleted from the context. The first packet built by the WAN Receive Controller is indicated to the receiving device by the toggling of the context switch bit in the Context Descriptor (see Figure 19). This triggers a context update cycle at the WAN Transmit Controller, ensuring the context update is correctly synchronized between the two devices.
Context Removal
Context removal is controlled by the use of the "teardown" control bit in the context memory. This causes the internal state machine to send one last packet, while automatically clearing all the flags in the Context Look-Up Table. As with context setup and modification, context removal has to be co-ordinated with that of the WAN Transmit Controller in the receiving device. This is described in Table 17 on page 39.
6.4.2
Jitter Buffer Operation
TDM packets received from the network are forwarded into a set of queues, while waiting for processing by the WAN Transmit Controller. Each context has a separate queue, used to buffer the constant bit rate TDM interfaces from the variable delays experienced in the packet network. The queues are therefore known as "jitter buffers". The WAN Transmit block reads packets from the jitter buffer at a regular rate, before re-formatting the data for transmission over the WAN Access Interface or the Local TDM interface. The size of jitter buffer translates directly into latency, since packets wait in the queue until the time to comes to be serviced. Most telecommunications applications are quite sensitive to latency, and attempt to minimise the overall end to end latency. However, if the jitter buffer is not big enough to cover the full variation in packet delay through the network (PDV), the buffer will either overflow or empty completely (underrun). Both of these conditions will result in data corruption. The initial size of the buffer is programmable in units of TDM frame periods (125 s). This is done by delaying the WAN Transmit Controller from reading the first packet received on a new context for the specified number of frames. This has the effect of setting the latency through the jitter buffer at the programmed value. However, the buffer can grow or shrink with time. When the variation in packet delay through the network is greater than the programmed buffer latency, occasional packets will arrive too late, and the TDM interface will be starved of data.
50
Zarlink Semiconductor Inc.
MT90880/1/2/3
Jitter Buffer Underrun
The jitter buffer will "underrun", i.e. empty completely under the following circumstances: * * * If the TDM data is played out of the TDM interfaces faster than the original TDM interface If the packet delay variation in the network is larger than the programmed jitter buffer If a large number of packets are lost in the network
Data Sheet
Either condition will have the effect that packets will arrive too late to be played out at the correct time, with the TDM interface being starved of data. When an underrun occurs, the TDM interface plays out "underrun data" for an integer number of TDM frames. Underrun data can either be the last value played out on that timeslot, or a pre-programmed value (e.g., 0xFF). When the late packet arrives, it is played out as normal. The net effect depends on the cause of the underrun. If the interface is underrunning because of a difference in frequency between the TDM clocks at either end of the network, the underrun introduces a frame slip every few frames, depending on the size of the frequency discrepancy. For example, if the frequency difference was 50 ppm, the frame slip will occur every 20,000 frames. The overall latency of the system will stay the same. If the underrun is being caused by a large PDV in the network, the depth of the jitter buffer (and hence the overall latency) for the underrunning context is increased by the number of frames that the packet is late. Over time, the buffer depth will increase to match the peak PDV in the network. The context descriptor protocol used by the MT9088x family has no sequencing information, so the device cannot tell when packets are lost in the network. When a packet is lost, it makes the next arriving packet look like a "late" packet. The next arriving packet is played out as soon as it arrives. This has the effect of reducing the jitter buffer depth. If enough packets are lost, this will start to cause underruns in the device, until the buffer depth is built back up to match the network PDV again.
Jitter buffer depth limitation
Packet delay variation in the network varies with time. As described above, the jitter buffer in the MT9088x family will track the peak level of PDV in the network. However, it will only track the PDV upwards. If there is a transient burst of activity in the network, the PDV may rise for a short period, and then settle back down again, but the buffer depth will remain at the level required to handle the peak PDV. For instance, if there was a link failure somewhere in the network, it could result in a large backlog of packets being stored up at a network node. When the link is restored, these packets may be released suddenly, creating a rush of very late packets. These packets will build up a large jitter buffer and a consequent increase in end to end latency. This may be undesirable in applications that are sensitive to the increased latency. The MT9088x provides a "drop threshold" limiting the maximum size of the queue to each context. When the queue depth reaches the drop threshold, any further packets arriving are discarded, preventing the size of the buffer and hence the end to end latency from increasing further. Different applications have different requirements for where to set the drop thresholds. Applications such as packet backplanes generally operate with tightly controlled networks with only a small variation packet delay. Therefore the drop thresholds for this type of application need to be small, and the MT9088x allows the drop thresholds to be set in increments of one packet, between 0 and 15 packets. However, for applications such as circuit emulation, while end to end latency is still important, the network is much larger and the packet delay variation cannot be as tightly controlled. Therefore the MT9088x provides a second range, where the thresholds can be set to increment by steps of 16 packets, between 15 and 255 packets. Where a packet contains a single TDM frame of data, this represents a step size of 2 ms. The two ranges are known as "backplane mode" and "network mode".
Jitter buffer overrun
The jitter buffer will "overrun", i.e., fill up completely under the following circumstances: * * If the TDM data is played out of the TDM interfaces slower than the original TDM interface If the packet delay variation in the network is larger than the programmed jitter buffer
51
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
The maximum size of the jitter buffer is governed by the drop threshold described above. When the drop threshold is reached, any further packets arriving are discarded until the buffer depth has reduced by being played out of the TDM interface. If the interface is overunning because of a difference in frequency between the TDM clocks at either end of the network, the overrun causes packets to be discarded at a constant interval, depending on the size of the frequency discrepancy. For example, if the frequency difference was 50 ppm, a packet will be discarded every 20,000 packets. However, since packets may contain multiple TDM frames, this may cause a more noticeable disturbance in the data stream than in the underrun case, where only a single frame slip occurs. If the underrun is being caused by a large PDV in the network, the overrun cause the depth of the jitter buffer to be limited to the maximum size, as described above.
6.5
Queue Manager
The Queue Manager is responsible for admission control, linking/dropping, and scheduling incoming packets either from WAN side, packet interfaces or from the PCI Interface. The Queue Manager provides a full spectrum of QoS (Quality of Service) features. For traffic queued to the packet interface, the Queue Manager provides four different priority levels. These can be managed either on a strict priority basis, or using Weighted Fair Queuing (WFQ). Similarly, the packet classifier can be used to direct traffic to four separate PCI interface queues. The host processor is responsible for managing the relative priority of each of these queues. For traffic queued towards the WAN interface, each separate packet stream or context is managed in a separate queue. The Queue Manager sets a programmable limit on the maximum number of packets in an individual context queue. This provides a means of detecting when the egress port has become broken, leading to the queues starting to fill up. Beyond the limit, incoming packets are dropped to avoid the memory becoming full, and therefore causing problems to the remaining contexts. Features include: * * Four separate queues to each port on the packet interface Queue disciplines on packet interface are:
* Weighted Fair Queuing with programmable weights * Strict Priority
* * * *
Separate queue for each WAN context Programmable drop threshold when queues get too big Four traffic classes on incoming packets Four separate queues to the PCI interface (host is responsible for any priority scheme)
6.5.1
Queues to the Packet Interface
The MT9088x family has four queues to each port of the packet interface. Each queue is used to provide a different class of service. TDM traffic from the WAN or Local interfaces can be allocated to a particular queue and port on a per-context basis. Similarly, packets from the CPU interface can be directed to any one of the queues and ports.
Classes of Service
The MT9088X uses two methods of queue control to provide for different classes of service: Strict Priority (SP), and Weighted Fair Queuing (WFQ). The queue disciplines can be allocated flexibly across the four different queues, as shown in Table 7.
52
Zarlink Semiconductor Inc.
MT90880/1/2/3
Options Class 3 Option 1 (default) Option 2 Option 3 Option 4 Class of Service Class 2 Class 1
Data Sheet
Class 0
SP SP SP WFQ
SP SP WFQ WFQ
SP WFQ WFQ WFQ
WFQ WFQ WFQ WFQ
Table 19 - Configuration of Packet Queues
Queues defined as strict priority take precedence over queues designated as using weighted fair queuing. Hence, in option 3, Class 3 gets all the bandwidth it needs, and the other classes are allocated a proportion of the remaining bandwidth. In effect, option 1 defaults to strict priority across all four queues, since Class 0 only gets serviced when there are no packets in the remaining SP queues.
Strict Priority
The Strict Priority queue system ensures that the queue with the highest priority is empty before transmitting any data from the next highest priority. For example in option 1, if the three queues for Classes 3, 2 and 1 each contained packets to transmit, all the packets in the Class 3 queue would be transmitted before packets from any other classes. The packets in the Class 2 queue will then be transmitted before any packets from Class 1. If more packets arrive in Class 3 while Class 2 or Class 1 packets are being transmitted, the new packet in Class 3 is automatically sent once the current packet has completed transmission. Any packets still in the Class 2 or Class 1 queues must wait until the Class 3 queue is empty again before they can be transmitted.
Weighted Fair Queuing
Weighted Fair Queuing allocates a portion of the available link bandwidth to each class. This prevents higher priority queues from "hogging" the link, since once they have used their allocated bandwidth, the other queues are given access to the link. In the MT9088x family, each class assigned to WFQ by the option settings is given a weight between 1 and 64. The bandwidth of each LAN port is 100 Mbs, and the weights assigned to each class represent a proportion of the bandwidth assigned to the queue. The sum of the weights must equal 64 for correct functionality. For example, if option 4 is selected the following weights might be programmed to set the appropriate bandwidth as shown in Table 20:
Class Weight % Bandwidth allocated
Class 3 Class 2 Class 1 Class 0
TOTAL
32 24 06 02 64
50.0 Mbs 37.5 Mbs 9.4 Mbs 3.1 Mbs 100 Mbs
Table 20 - Example of Weighted Fair Queuing
Weighted Fair Queuing doesn't set a maximum figure on the amount of bandwidth a queue gets allocated. If there are no other queues requiring service, a queue will continue to be serviced even if its bandwidth allocation is exceeded. The bandwidth allocation is only used to guarantee a minimum allocation to a particular traffic class, should it be required.
53
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
In the absence of a priority requirement, the weights should be set to the same value to allow equal access to the bandwidth. For example, in option 4 all the weights should be set to 16, allocating 25 Mbs per queue.
Drop Thresholds
The MT9088x has the ability to restrict the amount of memory used by each queue. When the memory utilisation reaches the limit, new packets are dropped. This limitation prevents a queue from increasing in size to the point where the device runs out of memory, causing the whole device to crash and lose data. For instance, this could potentially happen if an Ethernet link failed, causing a backlog of packets to build up in the queues to that link. The drop thresholds are programmed in units of granules, where a memory granule is a 128-byte block of data (see the section "Granule Structure" on page 64). For the queues to the packet interface, the thresholds can be set to between 0 and 1023 granules per queue. In addition, it is possible to set an overall threshold for the maximum number of granules allowed in all the queues to the packet interface at any one time. If required, it is possible to disable the packet dropping when the drop thresholds are exceeded, although this is not normally recommended. Exceeding the drop threshold causes an interrupt to the control CPU to inform it of the queue size violation, since this normally indicates some kind of error condition (e.g. an Ethernet link failure, as described above).
6.5.2
Queues to PCI Interface
The MT9088x maintains four separate queues of packets waiting for transfer to the CPU. These are for packets arriving over the network that either do not contain TDM data, or contain TDM data that needs processing by some external resource on the PCI bus (e.g. a DSP). The packet classification process is capable of identifying up to four different traffic classes, and can direct each of these traffic classes to a different queue. Unmatched traffic is always sent to CPU queue 0.
Priority of CPU Queues
The internal DMA controller is used to transfer packets from the MT9088x's packet memory into the system memory on the PCI bus (see the "DMA Controller" on page 71). While the CPU queues have no inherent priority levels associated with them, in that the CPU can choose to service which queue it wants to first, there is a priority level associated with the DMA transfer into system memory. The device uses strict priority order to determine which queue gets serviced first, with queue 3 having the highest priority and queue 0 the lowest priority. Therefore the DMA will only transfer packets in a given queue if all the higher priority queues are empty or stalled (queues may be stalled if there is no free space in system memory for them to be transferred into).
Drop Thresholds
As with the queues to the packet interface, there are also drop thresholds associated with the queues to the PCI interface. The drop thresholds are programmed in units of granules, and can be set to between 0 and 1023 granules per queue. Again, it is possible to disable packet dropping, although this is not normally recommended. Exceeding the drop threshold causes an interrupt to the control CPU to inform it of the queue size violation.
6.5.3
Queues to WAN Interface
The packet classifier identifies the packets arriving over the network that contain TDM data, and retrieves the context ID from the two-byte context descriptor. A separate queue is provided for each context, and the classifier forwards the packets to the appropriate queue. The WAN Transmit block reads packets from the end of the queue at a regular rate, and re-formats the data for transmission over the WAN Access Interface or the Local TDM interface. No priority is associated with these queues, since each WAN context is independent, and does not compete for resource against the other contexts.
54
Zarlink Semiconductor Inc.
MT90880/1/2/3
Drop Thresholds
Data Sheet
The context queues are used to buffer the constant bit rate TDM interfaces from the variable delays experienced in the packet network (see the section on "Jitter buffer Operation", on page 28). The initial size of this jitter buffer can be pre-programmed, but in cases where packets arrive very late across the network, the jitter buffer can grow. For instance, if there was a link failure somewhere in the network, it could result in a large backlog of packets being stored up at a network node. When the link is restored, these packets may be released suddenly, creating a rush of very late packets. These packets will build up a large jitter buffer and a consequent increase in end to end latency. Drop thresholds can be used to limit the size of this jitter buffer to a maximum value. Each of the queues to the TDM interfaces has a drop threshold that can be programmed in units of the number of packet in the queue. Packets arriving once this threshold has been reached are dropped, preventing the size of the buffer and hence the end to end latency from increasing further. Different applications have different requirements for where to set the drop thresholds. Applications such as packet backplanes generally operate with tightly controlled networks with small packet delay variations. Therefore the drop thresholds for this type of application need to be small, and the MT9088x allows the drop thresholds to be set in increments of one packet, between 0 and 15 packets. However, for applications such as circuit emulation, while end to end latency is still important, the network is much larger and the packet delay variation cannot be as tightly controlled. Therefore the MT9088x provides a second range, where the thresholds can be set to increment by steps of 16 packets, between 15 and 255 packets. Where a packet contains a single TDM frame of data, this represents a step size of 2 ms. The two ranges are known as "backplane mode" and "network mode", and are programmed by a bit in the queue manager control register. An overall threshold can also be set for the total amount of memory used by the queues to the TDM interfaces. This is set in units of granules, and has a maximum size of 65535 granules.
6.6
Packet Transmit
On transmission, a user defined static header is added to the packet payload. This contains the Ethernet header, the context descriptor, and the header required for the higher level protocols to be used (if any), e.g. IP, UDP. Since the header is completely user-defined, any high level protocol can be used provided the header does not change from packet to packet (e.g. contains a sequence number or a checksum across the payload).
6.6.1
Protocol Stacks
The MT9088x family can be used with a number of different protocol stacks. The common element is the use of the context descriptor for determination of the TDM context that the packet relates to. Examples of the most common expected stacks are (CDP = Context Descriptor Protocol): * Ethernet - CDP This is the most basic expected stack. Where the TDM traffic is only passed over a switched network, no upper layer headers are required. The Ethernet destination address is used to switch the packet to the correct destination, and the context descriptor used to determine the context. An Ethertype needs to be allocated to CDP to enable the traffic type to be determined in the packet classification process. * Ethernet - VLAN - CDP It is also possible to use a VLAN tag to switch the packets to the correct destination in the network. Again, an Ethertype needs to be allocated to CDP to enable the traffic type to be determined in the packet classification process. Ethernet - IPv4 - CDP
*
55
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Where packets have to sent across a routed network, rather than a simple switched Ethernet, IP can be used to provide the network layer. CDP can sit directly on top of the IP layer, but in this case a protocol number will need to be assigned. * Ethernet - IPv4 - UDP - CDP Where packets have to sent across a routed network, rather than a simple switched Ethernet, IP can be used to provide the network layer. The use of UDP as the transport layer enables TDM traffic from several different devices to be identified by use of different port numbers, and also removes the need for a protocol number to be assigned to CDP. Ethernet - MPLS - CDP An alternative to IP for a routed network is to use MPLS. An MPLS tunnel label in the header is used to route the packet across the network. An optional inner label could be used to identify different traffic classes, with the CDP fulfilling the role of a "Martini" style encapsulation layer.
*
6.6.2
Shadow Headers
The Packet Transmit block also maintains a "shadow" header for each context. This is used for context modification, for example addition of deletion of channels. Any header changes required by a context modification are programmed into the shadow header in advance. When the changes are complete, the "shadow" header is swapped with the existing header for the first packet containing the new context payload.
6.7
Ethernet MAC
The MT9088x family of devices contain two separate, IEEE standard 802.3 compliant, 10/100 Mbs Ethernet MACs (see reference 1, Table 2). Each MAC is connected to a Physical Layer (PHY) device via a Media Independent Interface (MII) or Reduced Media Independent Interface (RMII) (reference 3, Table 2). The MAC is responsible for data encapsulation/decapsulation. This includes frame alignment and synchronization, and detection of physical medium transmission errors. The MAC is capable of both full and half-duplex operation. In half-duplex mode it manages the collision avoidance and contention resolution process. In the event of a collision, the MAC will back off and attempt to re-send the packet up to 16 times. Packets for transmission are forwarded to the MAC by the Packet Transmit block. The MAC appends the frame check sequence, and generates the preamble and start of frame delimiter before transmitting out of the MII or RMII port. During packet reception, the MAC receive section verifies that the frame check sequence is correct, and that the packet is a valid length. Packets with an invalid frame check sequence, and data packets longer than 1518 bytes (1522 with VLAN tag) and shorter than 64 bytes are dropped. The MAC also checks the destination field to determine if the packet is intended for the device. If the packet is accepted, it is forwarded on for packet classification, and to be entered into the appropriate destination queue. Illegal packets, or packets intended for a different destination are discarded. The MAC also collects statistics on the different types of packets transmitted and received on the Ethernet. The statistics collected are sufficient to enable the CPU to support the Interfaces sections of some common MIBs. Features include: * * * * * * * IEEE 802.3 compliant operation at 10 and 100 Mbs Industry-standard MII and RMII interfaces to the physical layer devices Full and half-duplex operation Generates preamble, start-of-frame delimiter and frame check sequence Collision avoidance and contention resolution in half-duplex mode Verifies frame check sequence and frame length, discarding frames that contain errors Statistics collection for common MIB support:
56
Zarlink Semiconductor Inc.
MT90880/1/2/3
* * * * RFC 1213 MIB II. RFC 1757Remote Network Monitoring MIB (for SMIv1) RFC 2819Remote Network Monitoring MIB (for SMIv2) RFC 2863Interfaces Group MIB
Data Sheet
6.8
Packet Classification
This is used to determine the destination of incoming traffic on the packet interface from information contained in the packet header. Up to four separate traffic classes can be identified, and each class can be forwarded independently. Examples of traffic classes include TDM traffic for forwarding to the WAN interface, CPU control traffic, and traffic destined for a DSP or other off-chip processing element. Unidentified traffic is sent to the host processor via the lowest priority queue. Traffic classes are identified by matching the header against a pre-programmed pattern. If a pattern match is detected, the traffic can be directed to one of four separate queues to the host interface, or to the WAN interface. All WAN traffic must contain a two-byte adaptation layer (known as the context descriptor) in a known position within the first 64 bytes. This contains the context or packet stream to which the packet belongs, and other information required to synchronize to any changes to the contents of a particular context. Features include: * * * * * Four separate traffic classes Match on any field of combination of fields within the first 64 bytes Host traffic can be directed at one of four different queue Context Descriptor can be placed anywhere in the first 64 bytes (for TDM data packets) Can interface to devices placing the context descriptor in different places
6.8.1
Pattern Matching
Packet classification in the MT9088x is a three-stage process, as shown in Figure 26. Firstly, the packet header is masked, to concentrate the classification on the header fields of interest. Four separate masks are applied in parallel across the first 64 bytes of the packet. Next the masked header is compared against up to four possible patterns. Again, the comparison function is across the first 64 bytes of the packet. This depth of search allows fields from layer three and four headers to be included in the classification (e.g. IP and UDP headers).
57
Zarlink Semiconductor Inc.
MT90880/1/2/3
Incoming packet for classification Header Payload FCS
Data Sheet
Mask 1
Mask 2
Mask 3
Mask 4
Mask Stage
Masked Header
Masked Header
Masked Header
Masked Header
Pattern 1
Pattern 2
Pattern 3
Pattern 4
Comparison Stage
Comparator
Comparator
Comparator
Comparator
Comparison result 1
Comparison result 2
Comparison result 3
Comparison result 4
Priority Encoder
Pattern Match Result
Succesful Match
N
Forward to CPU queue 0
Y
Look-up Stage TDM traffic
Traffic Class
CPU Traffic
Look-up Context Descriptor
Look up CPU queue
Figure 26 - Packet Classification Process
Once a successful match is established, the characteristics of each traffic class may be determined by a look-up process. If the matched class contains TDM traffic, the context descriptor is retrieved from a pre-determined position. This indicates the identity of the context to which the packet belongs, which is used to place the packet into the appropriate queue. More than one traffic class can be designated as TDM traffic, allowing the context descriptor to be retrieved from a different position for each class. This may be useful when the MT9088x device received traffic from multiple sources, each of which may be using a different protocol stack. CPU traffic can be allocated to one of four queues waiting for DMA transfer up to the host. Therefore the classifier can be used to pre-sort the traffic destined for the CPU. This can be used either to direct traffic to different destination devices (e.g. packets for the control CPU, and packets for a DSP or local resource pool), or to separate high priority control traffic from lower priority maintenance information.
58
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Unmatched traffic is also forwarded to the CPU using queue 0. This allows the CPU to analyse the traffic to work out what should be done with it. Alternatively, if the drop threshold on queue 0 is set very small, unmatched traffic can be automatically discarded.
6.8.2
Example Classification Scheme
The following example shows how to set up the packet classification for a typical expected scenario. The MT9088x is expecting the following four classes of traffic: 1. 2. 3. 4. 5. TDM traffic using the protocol stack Ethernet - VLAN - CDP TDM traffic using the protocol stack Ethernet - IPv4 - UDP - CDP Data traffic to an external DSP using the protocol stack Ethernet - IPv4 - xxx CPU control traffic using the protocol stack Ethernet - IPv4 - TCP - xxx All other traffic - routed by default to CPU queue 0
Traffic Class 1: Ethernet - VLAN - CDP
Configure the mask and match registers in the packet engine to direct TDM traffic to the WAN interface.
Protocol Field Ethernet/VLAN Mask Match / Comment
Destination MAC address
Mask
If the MAC block is programmed into promiscuous mode then the destination MAC address must be matched,
Source MAC address Tag Type VLAN Tag Length / Type field
Context Descriptor
Mask Allow match Allow match Allow match Must be 0x8100 Must be set to the appropriate value for TDM traffic. Must be set to the appropriate type for TDM traffic. Will require allocation of an Ethertype by the IEEE.
Version Context Switch Context ID[11:7] Context ID[6:0] Remainder of the header
Allow match Mask Allow match Mask Mask
Must be 0b000
Must be 0b00000
Table 21 - Pattern Matching for Example Traffic Class 1
59
Zarlink Semiconductor Inc.
MT90880/1/2/3
Fields from Packet Engine Control Register:
Control Register Field Value Comment
Data Sheet
CPU_SEL1 CPU_PRI1 Byte offset to Context Descriptor
set to 0 don't care 18
TDM traffic Not CPU traffic 18 bytes in header before the CD
Table 22 - Control Register Fields for Example Traffic Class 1
Traffic Class 2: Ethernet - IPv4 - UDP - CDP
Configure the mask and match registers in the packet engine to direct TDM traffic to the WAN interface.
Protocol Field Ethernet Mask Match / Comment
Destination MAC address Source MAC address Length / Type field
IPv4
Mask Mask Allow match
If the MAC is programmed into promiscuous mode then the destination MAC address must be matched,
0x0800 (IP)
Version Internet Header Length (IHL) Type of Service (TOS) Total Length Identification Flags Fragment Offset Time to Live (TTL) Protocol Header Checksum Source IP address Destination IP address
UDP
Allow match Allow match Mask Mask Mask Allow match Mask Mask Allow Match Mask Mask Allow Match
0b0100 0d20
0b010 - Ensure set to don't fragment
0d17 (UDP)
Check the packet has the right IP address for TDM data.
Source Port Destination Port Length
Allow match Allow match Mask
Must be set to the appropriate value for TDM traffic. Must be set to the appropriate value for TDM traffic.
Table 23 - Pattern Matching for Example Traffic Class 2
60
Zarlink Semiconductor Inc.
MT90880/1/2/3
Protocol Field Mask Match / Comment
Data Sheet
Checksum
Context Descriptor
Mask
Version Context Switch Context ID[11:7] Context ID[6:0] Remainder of the header
Allow match Mask Allow match Mask Mask
Must be 0b000
Must be 0b00000
Table 23 - Pattern Matching for Example Traffic Class 2 (continued)
Fields from Packet Engine Control Register:
Control Register Field Value Comment
CPU_SEL2 CPU_PRI2 Byte offset to Context Descriptor
set to 0 don't care 0d42
TDM traffic Not CPU traffic 42 bytes in header before the CD
Table 24 - Control Register Fields for Example Traffic Class 2
Traffic Class 3: Ethernet - IPv4 - xxx
Configure the mask and match registers in the packet engine to direct data traffic to an external DSP processor on CPU DMA queue 2.
Protocol Field Ethernet Mask Match / Comment
Destination MAC address Source MAC address Length / Type field
IPv4
Mask Mask Allow match
If the MAC is programmed into promiscuous mode then the destination MAC address must be matched,
0x0800 (IP)
Version Internet Header Length (IHL) Type of Service (TOS) Total Length Identification
Allow match Allow match Mask Mask Mask
0b0100 0d20
Table 25 - Pattern Matching for Example Traffic Class 3
61
Zarlink Semiconductor Inc.
MT90880/1/2/3
Protocol Field Mask Match / Comment
Data Sheet
Flags Fragment Offset Time to Live (TTL) Protocol Header Checksum Source IP address Destination IP address Remainder of the header
Mask Mask Mask Mask Mask Mask Allow Match Mask Check the packet has the right IP address for external DSP traffic.
Table 25 - Pattern Matching for Example Traffic Class 3 (continued)
Fields from Packet Engine Control Register:
Control Register Field Value Comment
CPU_SEL3 CPU_PRI3 Byte offset to Context Descriptor
set to 0b1 set to 0b10 Don't care
Send packets to the CPU. Send to queue 2. Not TDM traffic
Table 26 - Control Register Fields for Example Traffic Class 3
Traffic Class 4: Ethernet - IPv4 - TCP - xxx
Configure the mask and match registers in the packet engine to control traffic to the CPU.
Protocol Field Ethernet Mask Match / Comment
Destination MAC address Source MAC address Length / Type field
IPv4
Mask Mask Allow match
If the MAC is programmed into promiscuous mode then the destination MAC address must be matched,
0x0800 (IP)
Version Internet Header Length (IHL) Type of Service (TOS) Total Length
Allow match Allow match Mask Mask
0b0100 0d20
Table 27 - Pattern Matching for Example Traffic Class 4
62
Zarlink Semiconductor Inc.
MT90880/1/2/3
Protocol Field Mask Match / Comment
Data Sheet
Identification Flags Fragment Offset Time to Live (TTL) Protocol Header Checksum Source IP address Destination IP address Remainder of the header
Mask Mask Mask Mask Allow Match Mask Mask Allow Match Mask Check the packet has the right IP address for CPU control traffic. 0d6 (TCP)
Table 27 - Pattern Matching for Example Traffic Class 4 (continued)
Fields from Packet Engine Control Register:
Control Register Field Value Comment
CPU_SEL4 CPU_PRI4 Byte offset to Context Descriptor
set to 0b1 set to 0b11 Don't care
Send packets to the CPU. Send to queue 3. Not TDM traffic
Table 28 - Control Register Fields for Example Traffic Class 4
6.9
Memory Management Unit
The Memory Management Unit handles all access to the external packet memory, arbitrating between the different modules requiring access. Efficient use of external memory is maintained by allocating memory in small blocks or "granules". Features include: * * * * * Interfaces to industry standard PBSRAM and ZBT SSRAM Operates at 66 MHz 32 bit wide data path Supports one to four equal sized memory banks Supports a total of between 0.125 and 8 Mbytes of memory
63
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.9.1 External Memory Requirements
Data Sheet
The majority of the memory is used by the jitter buffer, which compensates for delay variation (PDV) in the packet network. The amount of memory required to compensate for a given PDV depends on the mean size of the packet payload. This is because for small packets, a large proportion of the packet is actually header. The graph in Figure 27 shows the amount of packet delay variation that can be handled given the mean packet payload size and the size of the external packet memory.
250
Packet Delay Variation, ms
200
2 MByte memory
150 100 50 0 1 32 64 96 128 256 512 1024
1 MByte memory 512 KByte memory 256 KByte memory
Packet Payload size, bytes
Figure 27 - PDV Supported for Different Memory and Packet Payload Sizes
6.9.2
Granule Structure
Memory on the MT9088x family is dynamically allocated in 128 byte blocks, known as "granules". Each granule contains a 16-byte header section, used primarily for linking granules together into chains, and 112 bytes of data. The granular organization of memory is responsible for the discontinuities in the graph shown in Figure 27, as the packet size grows to consume another granule. The granule header contains information passed between the various internal blocks indicating how to handle the information contained within the granule. Most importantly, it contains a pointer field indicating the location of the next granule. This is used to chain granules together, initially to create large packets, and subsequently to link packets together into queues. To simplify flow of packets between functional blocks within the device, pointers are passed between blocks indicating the location of the packet in memory. These pointers actually contain the location of the first granule in a packet. Subsequent granules are indicated by the pointer field in the granule header. Free granules are held centrally in a pool managed by a granule manager block. When granules are required (e.g. during payload assembly or packet reception), the relevant block makes a request to the granule manager, which returns a pointer to a free granule. Similarly, when a granule (or chain of granules) is no longer required (e.g. the packet has been sent out of one of the output interfaces), it is released back to the free pool by sending a granule release request to the granule manager.
6.9.3
Connecting the MT9088x to External Memory
The MT9088x is capable of interfacing to two types of external memory device, pipelined burst SRAM (such as MicronTM's "SyncburstTM" family) and to the more bandwidth efficient types (such as MicronTM's "ZBT(R)" family), which remove the turnaround cycles required when changing from a read to a write cycle. For most applications, one external device is sufficient, as shown in the graph in Figure 27. All four memory capacities shown in this graph can be implemented using one device (either 4, 8 or 16 Mbs). However, for more
64
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
demanding applications, the MT9088x can connect to up to four external memory devices, with a total capacity of up to 8 Mbytes.
Connecting to a single external memory devices
The diagram in Figure 28 shows how to connect the MT90880 up to a single PBSRAM device. The example chosen is a MicronTM MT58L256L32P, an 8 Mbit "SyncburstTM" family SRAM. The clock to the memory is the 66 MHz system clock, used as the master clock to the MT90880 and the memory system. The memory is permanently chip enabled, with all chip enable signals (CE#, CE2# and CE2) tied to an active state. Read and write access is controlled by the MT90880 outputs RAM_OE[0]# and RAM_WE[0]#. The MT90880 only performs 32 bit wide accesses to memory, therefore the memory's individual byte write signals (BWa# to BWd#) are tied low. Write access to the full 32-bit word is controlled via the global write enable signal, GW#. Connection to a ZBT(R) device, such as the MT55L256L32P, is very similar, substituting the R/W# pin for the Syncburst's GW#, and tying the control pins LBO# and CKE# low.
MT9088x device
66 MHz System Clock
MicronTM generic SRAM
e.g. MT58L256L32P (256K x 32 bits SyncburstTM) CLK SA SA1 SA0 ADSC# GW# OE# DQa DQb DQc DQd ADSP# BWE# CE2 CE# CE2# BWa# BWb# BWc# BWd# ADV# MODE ZZ VSS VDD
S_CLK RAM_A[19:4] RAM_A[3] RAM_A[2] RAM_ADSC# RAM_WE[0]# RAM_OE[0]# RAM_D[7:0] RAM_D[15:8] RAM_D[23:16] RAM_D[31:24]
Figure 28 - Connecting the MT90880 to a Single External Memory Device
65
Zarlink Semiconductor Inc.
MT90880/1/2/3
Connecting to multiple external memory devices
Data Sheet
The four devices are connected in banks, and the MT90880 device automatically switches to the next bank when the address exceeds the range of the bank. Therefore the MT90880 needs to be informed during initialisation which memory size is being used. This affects the number of active address signals and the total available memory size, as shown in Table 17. Inactive address signals always output a low state. Connection to the memory devices is identical to that for a single memory device (see Figure 29), except that the four memory bank write enable signals, and the four memory bank output enable signals are connected to each memory device in turn, e.g. RAM_WE[0]# to device 1, RAM_WE[1]# to device 2, etc. All other connections and tie-offs are the same.
SSRAM size Total available capacity using 4 devices Active address signals
16 Mbs 8 Mbs 4 Mbs 2 Mbs 1 Mbs
8 Mbytes 4 Mbytes 2 Mbytes 1 Mbytes 0.5 Mbytes
20:2 19:2 18:2 17:2 16:2
Table 29 - Total Available Memory Size, Using Four External SSRAM Devices
66
Zarlink Semiconductor Inc.
MT90880/1/2/3
66 MHz System Clock
Data Sheet
MT9088x device
S_CLK RAM_A[19:4] RAM_A[3] RAM_A[2]
MicronTM generic SRAM e.g. MT58L256L32P MicronTM generic SRAM (256K x 32 MicronTM generic SRAM bits SyncburstTM) e.g. MT58L256L32P (256K x 32 MicronTM generic SRAM bits SyncburstTM) e.g. MT58L256L32P CLK
TM (256K x 32 bitsMT58L256L32P e.g. Syncburst ) ADSP# (256K x 32 bits SyncburstTM) SA ADSP# GW# CLK SA ADSP# CLK CE2 GW# SA ADSP# CE2 GW# SA1 SA CE# CE2BWE# SA1 CE2 CE2# CE# SA1 SA0 SA1BWa# CE2# CE# SA0 BWb# BWa# CE2# CE# SA0 SA0BWc# BWb# BWa# CE2# BWd# BWc# BWb# BWa# ADSC# ADV# BWd# BWc# BWb# ADSC# ADSC# MODE ADV# BWd# BWc# ADSC#ZZMODE ADV# BWd# GW# ZZMODE ADV# GW# ZZMODE GW# ZZ GW#
CLK
VDD
RAM_ADSC#
RAM_WE[0]# RAM_WE[1]# RAM_WE[2]# RAM_WE[3]# RAM_OE[0]# RAM_OE[1]# RAM_OE[2]# RAM_OE[3]# RAM_D[7:0] RAM_D[15:8] RAM_D[23:16] RAM_D[31:24]
VSS OE# OE# OE# OE# DQa DQa DQb DQb DQc DQc DQd DQd DQd DQd DQc DQc DQb DQb DQa DQa
Figure 29 - Connecting the MT90880 to Multiple External Memory Devices
6.9.4
External Memory Interface Timing
The timings for the external memory interface are shown in Table 39. However, calculations to see whether the MT90880 will be capable of operation with a particular memory device also depend on some external factors, notably the skew on the board between the system clock S_CLK at the MT90880 and the memory device. For example, the diagram in Figure 52 shows the memory write cycle. The MT90880 puts out the data on the bus at time TRDV following the rising edge of S_CLK. This has to meet a setup time to the next rising edge of S_CLK at the RAM (TDS). However, if the clock is skewed on the board such that S_CLK is slightly earlier at the RAM than at the MT90880, the setup time is effectively increased by the amount of skew. The maximum clock skew between devices can be determined from the following equation: Maximum allowable clock skew = TS_CLK - TRDV - TDS For a Micron MT58L256L32P, the minimum RAM data setup time TDS is 1.5 ns when using the 7.5 ns speed grade part. TRDV is 10 ns (from Table 41) and with S_CLK running at 66 MHz, the clock period TS_CLK is 15.15 ns. Therefore,
67
Zarlink Semiconductor Inc.
MT90880/1/2/3
Maximum allowable clock skew = 15.15 - 10 - 1.5
Data Sheet
= 3.65 ns This time must be reduced by transmission times of signals across the board between the MT90880 and the memory, e.g. RAM_WE[x]# and the data bus, so in practice, the clock skew must be somewhat lower than this figure suggests. The read cycle (Figure 50) is not affected by clock skew in the same way. The MT90880 puts out an output enable, RAM_OE[x]#, a time TRAV after S_CLK. In response, the RAM puts the data out onto the bus within a response time (TOEQ), and this data has to meet a setup time T RDS to S_CLK back at the MT90880. Since both the output enable and data setup are timed to the clock at the MT90880, board level clock skew does not influence the read cycle timing. Therefore the maximum allowable RAM output valid time TOEQ is determined by the equation: Max. allowable RAM output valid time = TS_CLK - TRAV - TRDS = 15.15 - 7.5 - 3 = 4.65 ns For a 7.5 ns speed grade MT58L256L32P, the RAM output valid time TOEQ is 4.2 ns. This part therefore meets the required time with 0.45 ns to spare, although as before, some allowances should also be made for transmission time of the control and data signals across the board.
6.10
PCI Interface
This is a full master/target capable PCI bus interface capable of operation at 33 MHz. Since it has a data width of 32 bits, this can provide up to 1 Gbit/s of data transfer. The PCI interface can be used by an external CPU to provide full access to on-chip registers, and both on-chip memory and the main off-chip packet memory, via the memory management unit. It also contains a DMA controller, which can be used to automatically transfer data between off-chip packet memory and system memory on the PCI bus. The PCI Core is fully compliant with the PCI Rev 2.2 Specification (reference 2, Table 2) provided by the PCI Special Interest Group (PCI-SIG) responsible for global PCI Standards. Note that signals pci_serr# and pci_inta# are not open drain, and require external circuitry so that the board itself, on which the MT9088x is used, is PCI compliant. See "Open Drain Circuitry" on page 71. Features include: * * * * * * PCI revision 2.2 compliant 33 MHz operation 32 bit wide data bus Master/Target capable Scatter/gather DMA controller, capable of following down a linked list of packets for transfer Allows target access to all on-chip registers and memory, and to external packet memory
6.10.1
Address and Data Width support
The MT9088x family PCI interface only supports 32-bit PCI addressing and 32-bit wide PCI data transactions. If an 8 or 16 bit data transaction is attempted, the MT9088x responds as though the transaction is 32 bits wide. Hence an 8 or 16 bit read will result in the full 32 bits being placed on the PCI databus, and an 8 or 16 bit write will result in the full 32 bits on the data bus being written into the register or memory location. The MT9088x requires the master to break 64 bit transactions into two 32 bit accesses, in accordance with the PCI revision 2.2 specification (section 3.2.3).
68
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.10.2 Target Transaction Support
Data Sheet
Supported Transactions
The MT9088x family supports the following PCI target transactions: * * * * Memory read (single cycle only) Memory write (single cycle only) Configuration read Configuration write
Burst Transactions
Burst transactions are not supported by the MT9088x. The device will respond with a Target Disconnect cycle if a burst access is attempted.
Timeout on Target Read
A PCI Read access timeout is available, set to 32 system clock cycles (485 ns). A timeout will not generate an interrupt or an error, but will result in the data read being 0xFFFFFFFF. The timeout can be disabled.
Fast Back to Back cycles
The MT9088x is capable of receiving fast back to back cycles as a PCI Target device.
PCI Error, Abort and Re-try sources
The following events are among those that will cause a PCI error or abort or re-try event to occur. * * Address Parity error: A Target cycle to the MT9088x with an Address Parity error will cause a PCI System Error to be generated. Data Parity error: A Target write cycle to the MT9088x with a Data Parity error will cause a PCI Parity Error to be generated.
6.10.3
Master Support
The MT9088x becomes a PCI Master whenever DMA accesses are invoked to transfer packets from the external packet memory to the Host CPU or vice versa using the DMA controller. One PCI Bus request output and one PCI Bus grant input is provided to allow the MT90880 to request and be granted the PCI bus. The MT90880 does not generate Fast Back to Back cycles when in Master mode.
Transaction Timeout counters
When the MT9088x is a Master on the PCI bus, two counters are provided to allow the system to recover in the event of the PCI Target behaving abnormally: The TRDY timeout counter is programmable, and holds the number of cycles the Master will wait before abandoning the cycle. Reasons for timing out include the absence of the TRDY or Stop signals to terminate the cycle normally. This timeout can be disabled. The Retry timeout counter allows the user to limit the number of re-try cycles that the MT90880 as PCI Master will attempt before abandoning the cycle. This timeout can be disabled.
6.10.4
Configuration and Registers
The MT9088x is configured as a PCI Satellite device. Therefore the PCI interface must be configured by the Host PCI device connected to the bus before the internal register and memory space can be accessed by the Host. This is achieved by programming the device PCI configuration registers.
69
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
The PCI configuration registers are used to set up how the MT9088x will fit into the system in which it will be placed. They support the method defined in the PCI Rev 2.2 Specification to determine the size of the memory spaces required by the MT9088x so that the System Host can allocate enough memory. They also contain manufacturer ID information, along with device and revision identifiers, base addresses for the internal register and memory spaces, and various control and status fields. The MT9088x does not include Vital Product Data information or support. It is not possible to use the MT9088x itself as a PCI Host, and the MT9088x does not provide PCI bus Arbitration capabilities. The configuration registers are detailed in the document "MT90880 Programmers' Model" (related document 1).
Memory Map
The following diagram (Figure 30) represents the 32-bit PCI bus, and how the address allocation for MT90880 and the External Packet Memory are seen from a system point of view. The register and memory base addresses are programmable, and form part of the MT90880 PCI Configuration registers set.
0x00000000
Register Base Address
Allocated to MT90880 by system software (128 KB of 16MB used)
Memory Base Address
Allocated to MT90880 by system software (up to 8MB of 16MB used)
0xFFFFFFFF
Internal Register & Memory space of MT90880 External Packet Memory space of MT90880
Figure 30 - MT90880 Memory and Register Space Organization
System Software Reset
The MT90880 has the capability for a software-initiated reset. The PCI interface can be excepted from the general reset if required, by programming a bit in the system control register. This prevents the software reset from destroying the PCI configuration state, allowing the Host CPU to continue to access the device without having to re-program the configuration data.
6.10.5
Signalling Environment
The MT9088x PCI Interface is compatible with a 3.3V PCI signalling environment and can be directly connected to other similarly compatible devices in that environment. The 5 V PCI signalling environment is not supported as the MT9088x PCI Interface is not 5 V tolerant.
70
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.10.6 Open Drain Circuitry
Data Sheet
The MT9088x signals pci_serr# and pci_inta# do not behave as open drain. Signals pci_serr# and pci_inta# should behave as open drain. The following external circuitry should be used, so that the board on which the MT9088x is placed, is compliant with the PCI specifications. Note any other circuitry such as termination resistors, pull-up resistors, etc. are not shown.
VDD33
pci_serr# (AB24)
MT9088x
pci_inta# (AF19)
Quad Open Drain Buffer
to PCI Backplane (3.3V)
Figure 31 - pci_serr#, pci_inta# Open Drain Circuitry
6.11
DMA Controller
The MT9088x contains a DMA Controller, automating transfer of data packets between the CPU system memory and the MT9088x's external packet memory (Figure 32). This can be used to send packets from the CPU into the packet network, and to direct packets received from the network to the CPU.
Host CPU
System memory PCI Bridge DMA transfer PCI Bus
MT90880
External packet memory
Figure 32 - DMA Transfer to/from System Memory
71
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.11.1 DMA Descriptor Rings and Lists
Data Sheet
Data for transfer to and from the MT90880 is held in a Descriptor Ring or List data structure in system memory (see Figure 33 and Figure 34). Once the CPU has set up the descriptor structure, the DMA engine is simply told where to find the head descriptor. The DMA engine co-ordinates the transfer of packets to and from the data structures with minimal further CPU intervention. The "ring" data structure (Figure 33) allows a circular buffer to be created. Once the descriptors have been set up, they should never need re-programming, save to change the relevant status and command bits. The ring data structure is useful when a finite size buffer is allocated for packet transfer.
Head Descriptor Link Command Buffer Pointer Status Link Command Buffer Pointer Status Link Command Buffer Pointer Status Link Command Buffer Pointer Status
Data Buffer
Data Buffer
Data Buffer
Data Buffer
Figure 33 - Descriptor Ring Structure
A list structure (Figure 34) may also be used. This is similar to the ring, but final link pointer does not point back to the head descriptor. This is useful where a more elastic buffer is required, but requires more CPU intervention, since once the list has completed, it is necessary to re-program the DMA to point to the next set of descriptors.
72
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Head Descriptor Link Command Buffer Pointer Status Link Command Buffer Pointer Status Link Command Buffer Pointer Status Link Command Buffer Pointer Status End
Data Buffer
Data Buffer
Data Buffer
Data Buffer
Figure 34 - Descriptor List Structure
Full details of the DMA descriptor data structures, and the fields within the descriptor, are provided in the "MT90880 Programmers' Model " (related document 1).
6.11.2
Data Transfer from CPU to MT90880
For data transfer from the CPU to the MT90880 (denoted "P2L", or Processor to LAN traffic), the DMA engine transfers packets until it reaches the end of the populated data structure. An interrupt can be generated each time a packet is transferred, or alternatively, it can be programmed to occur once the whole populated structure has been transferred. Data transfer is resumed on CPU command once there are more packets to transfer in system memory.
Packet and Descriptor Queues
The MT9088x family devices contain four separate queues to each port in the packet interface. These four queues are assigned different priorities, enabling different classes of service to be defined. Fields within the descriptor command direct the packet to the appropriate queue and port. In addition, the device supports the use of two entirely separate descriptor structures for P2L traffic. One of these, P2L queue 0, is given higher priority than the other, P2L queue 1. This enables high priority traffic from the CPU to be given preferential access to the DMA. The ratio of DMA bandwidth allocated to each queue can be adjusted from 2:1 in favour of P2L queue 0, to 8:1. Alternatively, strict priority may be used, where packets in P2L queue 1 only get transferred if there are no packets in P2L queue 0. This is the default option.
6.11.3
Data Transfer from MT90880 to CPU
For data transfer from the MT90880 to the CPU (denoted "L2P", or LAN to Processor traffic), the DMA automatically transfers packets as they arrive from the network. The data is placed into the data buffers in system memory until either the data structure is full or there are no more packets to transfer. When subsequent packets arrive, data transfer is resumed automatically, provided that the structure is not full. An interrupt may be generated each time a packet is transferred to inform the CPU that there is a packet ready to be read, alternatively the CPU can periodically poll the descriptor status to check for new packets. The CPU can process the incoming packet stream at any rate it chooses because the DMA will suspend the transfer when there are no empty descriptors available.
CPU Queues
The MT90880 maintains four separate queues of packets waiting for transfer to the CPU. Each queue has a corresponding descriptor list or ring held in System Memory (see Figure 35). Packets are classified as they are received by the device to determine their destination. The classification process can identify up to four separate traffic types, and each type placed into one of the four queues or directed to the TDM domain. Unmatched traffic is always sent to CPU queue 0.
73
Zarlink Semiconductor Inc.
MT90880/1/2/3
MT90880
Packet Classification CPU queues Descriptor lists in System Memory Ring/List 0 L2P queue 0 Ring/List 1 Search the incoming packets for a match and forward to the appropriate queue L2P queue 1 Ring/List 2 L2P queue 2 Ring/List 3 L2P queue 3
Data Sheet
Figure 35 - DMA Operation from CPU Packet Queues
Queue Priority
While the CPU queues have no inherent priority levels associated with them, in that the CPU can choose to service which queue it wants to first, there is a priority level associated with the DMA transfer into system memory. The MT90880 uses a prioritised round robin methodology to determine which queue gets serviced first, with L2P queue 3 having the highest priority and L2P queue 0 the lowest priority. Therefore the DMA will only transfer packets in a given queue if all the higher priority queues are empty. However, this is only true if there is room in the corresponding data structure in system memory for the DMA to transfer into. If there are no empty data buffers for a particular queue then that queue will be stalled, irrespective of its priority. The DMA engine will then continue to service the lower priority queues. Therefore the CPU can also control the priority by how fast it processes each queue.
6.12 6.12.1
Board Level Test Features JTAG Support
The JTAG port is used to access the boundary scan logic for board level production testing. A NAND tree test mode is also provided on the MT9088x family. The MT9088x JTAG interface conforms to the IEEE standard 1149.1 (reference 4, Table 2). This standard specifies a design-for-testability technique called "Boundary-Scan Test" (BST). An external Test Access Port (TAP) Controller controls the operation of the boundary scan circuitry. Details of the contents of the scan register are contained in the BSDL file.
74
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.12.2 Test Access Port (TAP)
Data Sheet
The Test Access Port (TAP) accesses the MT9088x test functions. It consists of four input pins and one output pin as follows:
Test Clock Input (TCK)
TCK provides the clock for the test logic. The TCK does not interfere with any on-chip clock and thus remains independent. The TCK permits shifting of test data into or out of the Boundary-Scan register cells concurrently with the operation of the device and without interfering with the on-chip logic.
Test Mode Select Input (TMS)
The TAP Controller uses the logic signals received at the TMS input to control test operations. The TMS signals are sampled at the rising edge of the TCK pulse. This pin is internally pulled to VDD when it is not driven from an external source.
Test Data Input (TDI)
Serial input data applied to this interface is fed either into the instruction register or into a test data register, depending on the sequence previously applied to the TMS input. Both registers are described in a subsequent section. The received input data is sampled at the rising edge of TCK pulses. This pin is internally pulled to VDD when it is not driven from an external source.
Test Data Output (TDO)
Depending on the sequence previously applied to the TMS input, the contents of either the instruction register or data register are serially shifted out towards the TDO. The data out of the TDO is clocked on the falling edge of the TCK pulses. When no data is shifted through the boundary scan cells, the TDO driver is set to a high impedance state.
Test Reset (TRST)
Reset the JTAG scan structure. This pin is internally pulled to VDD.
6.12.3
Test Access Registers
Instruction Register
The MT9088x uses the public instructions defined in the IEEE 1149.1 standard. The JTAG Interface contains a two-bit instruction register. Instructions are serially loaded into the instruction register from the TDI when the TAP Controller is in its shifted-IR state. These instructions are subsequently de-coded to achieve two basic functions: to select the test data register that may operate while the instruction is current; and, to define the serial test data register path that is used to shift data between TDI and DO during data register scanning.
Test Data Register
As specified in IEEE 1149.1, the MT9088x JTAG Interface contains three test data registers:
Boundary-Scan Register
The Boundary-Scan register consists of a series of Boundary-Scan cells arranged to form a scan path around the boundary of the MT9088x core logic.
Bypass Register
The Bypass register is a single stage shift register that provides a one-bit path from TDI to its TDO.
Device Identification Register
The device identification register is a 32-bit register. The register contents are included in the BSDL file for the chip.
75
Zarlink Semiconductor Inc.
MT90880/1/2/3
6.13 DPLL Specification
Data Sheet
The MT9088x contains an internal Digital Phase Locked Loop (DPLL) which exceeds the requirements of Stratum 4E. This is provided both to synchronise to external references and generate the internal clocks required by the device when operating in synchronous mode. The DPLL accepts two references, primary and secondary, selected from the incoming ports on the WAN Access Interface. Failure of a reference is automatically detected, and the DPLL can switch between references without introducing bit errors. Reference switching can be performed under automatic or manual control. The DPLL operates in two main modes, "Master" and "Slave". In Master mode, the DPLL accepts an incoming 8KHz frame reference, and generates a stable, low jitter clock and frame pulse for the selected data format. Master mode is generally used where the MT9088x is supplying the clocks to the TDM infrastructure, for example, T1/E1 framers, or a TDM backplane such as H.110 or H-MVIP.
In Slave mode, both the incoming and outgoing streams are timed using the external reference, bypassing the
DPLL. The DPLL locks to both the clock and the frame pulse, and generates the internal clocking for the device. This mode is used where the master clock and frame references are provided externally. Features include: * * Exceeds Stratum 4E standard Three fundamental modes of operation: * * * * * * * "Master" clock-generator mode - locks to incoming 8KHz frame reference "Slave" clock-follower mode - locks to incoming clock and frame reference "Free-run" mode allows clock generation without an external reference
Primary and secondary references Automatic detection of reference failure Holdover operation, maintaining last locked reference frequency Error-free reference switching, meeting Telcordia GR-1244-CORE (reference 10, Table 3)
6.13.1
Master Mode
In master mode, the DPLL locks to an incoming 8KHz frame reference. It generates the clock and frame pulses required by the selected data format on the WAN Access Interface (see Table 7 on page 16). From a device reset condition or after a reference switch, the DPLL will take up to 50 seconds to phase lock the output signals to the selected input reference signal.
Primary and Secondary References
The DPLL can operate with two references, a primary and a secondary, selected from any of input frame references. The health of both selected references is continuously monitored. When an incoming reference fails, the DPLL can either automatically switch to the alternate reference, or enter holdover operation. The reference switch can then be manually controlled. Should the failed reference return, the device will re-lock to the reference. The DPLL provides bit error free reference switching, meeting the phase slope and MTIE requirements defined by the Telcordia GR-1244-CORE standard (reference 10, Table 3).
Holdover Operation
In Holdover, the DPLL maintains the clock frequency at the value recorded before the reference was judged to have failed. Holdover is typically used for short durations while network synchronization is temporarily disrupted. The initial accuracy of the held frequency is 0.06 ppm, which translates in the worst case to 42 frame (125 s) slips in 24 hours.
76
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Two factors affect the frequency stability while in Holdover. The first factor is the drift on the master clock (S_CLK) frequency. Any drift in master clock frequency translates directly into drift on the holdover frequency. Note that the absolute master clock accuracy does not affect the stability of the held frequency, only changes in the master clock frequency while in holdover mode. For example, a 32 ppm master clock may have a temperature coefficient of 0.1 ppm/0C. So, a 100C change in temperature may result in an additional frequency offset of 1 ppm, over and above the intrinsic accuracy of 0.06 ppm. The second factor affecting stability is any large frequency jitter on the reference input prior to the reference failure. This could cause the measured frequency to be inaccurate, resulting in an incorrect holdover frequency.
Jitter Transfer
In master mode, jitter on the incoming reference is attenuated by both a Phase Slope Limiter and the internal Loop Filter. The Phase Slope Limiter limits the output phase slope to 7 ns per 125 s. Therefore, even if the phase slope of the input signal exceeds this rate, such as for low frequency input jitter with a very large amplitude, the maximum output phase slope will be limited to 7 ns per 125 s. The internal loop filter is a single pole low-pass filter with a cutoff frequency of 1.25 Hz. This progressively attenuates all jitter above the cutoff frequency at a rate of 20 dB/decade. Figure 36 shows the DPLL jitter transfer function diagram across a wide range of frequencies, while Figure 37 is the portion of the diagram from Figure 36 around 0dB of the jitter transfer amplitude. From this diagram it is possible to see that the DPLL is a second order, type 2 PLL.
Figure 36 - DPLL Jitter Transfer Function Diagram Across a Wide Range of Frequencies
77
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Figure 37 - Detailed DPLL Jitter Transfer Function Diagram
All outputs are derived from the same signal, therefore these diagrams apply to all outputs. Using the method mentioned above, the jitter attenuation can be calculated for all combinations of inputs and outputs.
Frame alignment
When operating in master mode, the incoming frame reference is used solely as a frequency reference. There is no requirement on the width of the frame pulse. The output frame pulse must therefore be used as the master for the devices connected to the MT9088x's WAN Access Interface. There is no guaranteed phase relationship between the input frame pulse and the output master frame pulse.
6.13.2
Slave Mode
Slave mode is used where the master clock and frame references are provided externally. Both the incoming and outgoing streams are timed using the external reference, bypassing the DPLL. The DPLL locks to the incoming clock and frame pulse, and is used solely to generate the internal clocks required by the device. The input frequency combinations and frame pulse widths for correct slave mode operation are given in Table 7 on page 16. These correspond to the data formats selected for the WAN Access Interface. When operating in slave mode, the MT9088x is capable of accepting timing references with jitter meeting ITU-T standards G.823 and G.824 when operating in either Generic E1 or ST-Bus formats at 2.048 Mbs. When operating in ST-bus format at 8.192 Mbs, the maximum allowable input jitter above 10 KHz is 61 ns (1 UI at the input clock rate of 16.384 MHz). This translates to 0.125 UI at 2.048 MHz, or just outside the G.824 specification of 0.2 UI.
6.13.3
Free-run Mode
In the Free-run Mode, the DPLL provides timing and synchronization signals, which are based on the frequency of the master clock (S_CLK) only, and are not synchronized to a reference input. The DPLL outputs have a frequency accuracy of 0.005 ppm plus the accuracy of the master clock. For example, clock output C8OB will have a frequency of 8.192 MHz S_CLK accuracy 0.005 ppm).
78
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Free-run Mode is typically used when a master clock source is required, or immediately following system power-up before network synchronization is achieved.
6.13.4
DPLL Performance Parameters
Table 30 lists the key performance parameters of the DPLL.
Parameter Min Max 3.8 245 Units Comment
Intrinsic jitter Lock range Lock time Free-run frequency accuracy
ns ppm s ppm
Note 1 Note 2
50
0.005
Note 3
Master Mode Parameters (the following parameters are only applicable in master mode):
Phase slope output Holdover frequency accuracy MTIE during a reference switch
56
0.06
ppm ppm ns
Note 4 Note 5
20
Slave Mode Parameters (the following parameters are only applicable in slave mode):
Input clock jitter tolerance (above 10 KHz)
1
UI
Note 6
Table 30 - DPLL Performance Parameters
Note 1: For the DPLL, the intrinsic output jitter is determined by the frequency of the master clock input (S_CLK). The edges of the DPLL output clocks are synchronous to both edges of the master clock, giving a resolution of 7.6 ns for a 66 MHz clock. In addition, any jitter present on the master clock is transferred without attenuation to the output clocks. Note that the locking range is related to the master clock frequency (S_CLK). For example, if the master clock is -100 ppm, the whole locking range also shifts -100 ppm downwards from -345ppm to 145ppm. Assumes ideal master clock (S_CLK) frequency of 66.0 MHz. Any deviation of master clock frequency from 66 MHz directly translates into a degradation of free-run frequency accuracy. This is equivalent to 7ns per 125 s, or better than specified in GR-1244-CORE (reference 10) which states that the phase slope may not exceed 81 ns/1.327 ms (61 ppm). Assumes no drift on the master clock (S_CLK) frequency. Any drift in master clock frequency after holdover is entered will translate directly into a holdover frequency error. Maximum jitter is 1 UI (1 bit period) of input clock frequency. With input clock frequencies of 2.048 MHz and 4.096 MHz, this comfortably exceeds ITU-T standards G.823 and G.824 (references 11 and 12). With a 16.384 MHz input clock, this translates to 61 ns, or 0.125 UI at 2.048 MHz. This is just outside the G.823 specification of 0.2 UI.
Note 2: Note 3: Note 4: Note 5: Note 6:
7.0
Memory Map and Register definitions
Details of the memory map and register definitions are included in the document "MT90880 Programmers' Model" (related document 1).
8.0
Special Note to Users: MT9088x handling of received corrupted Ethernet packets and dealing with the next valid packet
Issue
8.1
Whenever the MT9088x device receives Ethernet packets which are corrupted (CRC error, too short or too long etc.) the context related to the error packet will have incorrect data. The next valid packet following the error packet will be lost and this may belong to a different context.
79
Zarlink Semiconductor Inc.
MT90880/1/2/3
8.2 Recommendation
Data Sheet
This device should not be used in a half-duplex network application. The final link to the device should be as short as possible, (for example from an Ethernet Switch), in order to minimise the probability of corrupted packets on the link.
9.0
DC Characteristics
Voltage measurements are with respect to ground (VSS) unless otherwise stated.
Absolute Maximum Ratings Parameter
Symbol
Min.
Max.
Units
I/O Supply Voltage Core Supply Voltage PLL Supply Voltage Input Voltage Input Voltage (5 V tolerant inputs) Continuous current at digital inputs Continuous current at digital outputs Package power dissipation Storage Temperature
VDD_IO VDD_CORE VDD_PLL VI VI_5 V IIN IO PD TS
-0.5 -0.5 -0.5 -0.5 -0.5 -55
5.0 2.5 2.5 VDD + 0.5 7.0
10 15
V V V V V mA mA W
C
4 +125
Note: Exceeding these figures may cause permanent damage. Functional operation under these conditions is not guaranteed.
The core and PLL supply voltages must never be allowed to exceed the I/O supply voltage by more than 0.5 V during power-up. Failure to observe this rule could lead to a high-current latch-up state, possibly leading to chip failure, if sufficient cross-supply current is available. To be safe ensure the I/O supply voltage supply always rises earlier than the core and PLL supply voltages.
80
Zarlink Semiconductor Inc.
MT90880/1/2/3
Recommended Operating Conditions Characteristics
Data Sheet
Voltage measurements are with respect to ground (VSS) unless otherwise stated.
Symbol
Min.
Typ.
Max.
Units C C C/w
Test Condition
Operating Temperature Junction temperature Package thermal resistance to ambient Positive Supply Voltage, I/O Positive Supply Voltage, Core Positive Supply Voltage, Core Input Voltage Low - all inputs Input Voltage High Input Voltage High, 5 V tolerant inputs
TOP TJ
JA
-40 -40
25
+85 125
33 3.0 1.65 1.65 3.3 1.8 1.8 3.6 1.95 1.95 0.8 2.0 2.0 VDD_IO 5.5
VDD_IO VDD_CORE VDD_PLL VIL VIH VIH_5 V
V V V V V V
Note: Typical figures are at 25C and are for design aid only.
DC Characteristics Characteristics Symbol Min. Typ. Max. 1 Units A A Test Condition
Input Leakage Output (High impedance) Leakage Input Capacitance Output Capacitance Pullup Current Pulldown Current Core 1.8V supply current PLL 1.8V supply current I/O 3.3V supply current
ILEIP ILEOP CIP COP IPU IPD IDD_CORE IDD_PLL IDD_IO 100 2 4 -33 33 220
No pull up/down VDD = 3.6 V No pull up/down VDD = 3.6 V
2
pF pF
A A
Input at 0 V Input at VDD Note 1
mA 1.25 mA m
Typical characteristics are at 1.8 V core, 3.3 V I/O, 27C and typical processing. The min and max values are defined over all process conditions, from -40 to 125C junction temperature, core voltage 1.65 to 1.95 and I/O voltage 3.0 and 3.6 V unless otherwise stated. Note 1: There are two analog PLLs with separate 1.8 V supplies. Each supply consumes current of IDD_PLL.
81
Zarlink Semiconductor Inc.
MT90880/1/2/3
9.0.1 Input Levels
Characteristics Symbol Min. Typ. Max. Units
Data Sheet
Test Condition
Input Low Voltage Input High Voltage Positive Schmitt Threshold Negative Schmitt Threshold
VIL VIH VT+ VT2.0 1.6 1.2
0.8
V V V V
9.0.2
Output Levels
Characteristics Symbol Min. Typ. Max. Units Test Condition
Output Low Voltage Output High Voltage Output Low Current Output High Current Output Low Current Output High Current Output Low Current Output High Current
Note 1: Note 2:
VOL VOH IOL IOH IOL IOH IOL IOH 2.4 1.6 1.2 1.6 1.2 1.6 1.2
0.4
V V mA mA mA mA mA mA PCI Bus PCI Bus Note 1 Note 1 Note 2 Note 2
WAN and Local TDM busses. External RAM busses, except for RAM_CLK. T_D bus. RAM_CLK. MII and RMII busses except M1_TXEN, M0_TXEN and M_MDC
82
Zarlink Semiconductor Inc.
MT90880/1/2/3
10.0
10.1 10.1.1
Data Sheet
AC Characteristics
WAN Access Interface Slave Clock Mode
Data format Parameter Symbol Min. Typ. Max. Units Notes
ST-bus 8.192 Mbs mode
WAN_CLKI frequency WAN_CLKI High Width WAN_CLKI Low Width
fC16P tC16H tC16L fC4P tC4H tC4L fC2P tC2H tC2L tFOIS tFOIH tSTOD tSTIS tSTIH 5 5 1 5 5
16.384 30 30 4.096 122 122 2.048 244 244
MHz ns ns MHz ns ns MHz ns ns ns ns 20 ns ns ns
Note 1
ST-bus 2.048 Mbs mode
WAN_CLKI frequency WAN_CLKI High Width WAN_CLKI Low Width
Note 1
Generic E1 2.048 Mbs mode
WAN_CLKI frequency WAN_CLKI High Width WAN_CLKI Low Width
Note 1
All modes
WAN_FRMI Setup Time WAN_FRMI Hold Time WAN_STO Delay WAN_STI Setup Time WAN_STI Hold Time
Table 31 - WAN Access Interface Timing - Slave Mode
Note 1: In synchronous mode the clock must be within the locking range of the DPLL to function correctly (245 ppm). In asynchronous mode, the clock may be any frequency, provided there are 32 clocks between frame pulses (128 in 8.192 Mbs mode)
Channel 31 Bit 0 tC4L WAN_CLKI
Channel 0 Bit 7 tC4H
Channel 0 Bit 6
tFOIH tFOIS WAN_FRMI tSTIH tSTIS B0 tSTOD WAN_STO Ch 31 Bit 0 Ch 0 Bit 7 tSTIH tSTIS B7 tSTOD Ch 0 Bit 6
WAN_STI
Figure 38 - WAN Bus Slave Mode Timing at 2.048 Mbs
83
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Channel 31 bit 0 WAN_CLKI
Channel 0 bit 7 tC2L tC2H
Channel 0 bit 6
tFOIH tFOIS WAN_FRMI tSTIH tSTIH WAN_STI tSTOD Channel 31 bit 0 tSTOD Channel 0 bit 7 tSTOD Channel 0 bit 6
WAN_STO
Figure 39 - WAN Bus Slave Mode Timing at 2.048 Mbs Generic E1 Mode
Channel 127 bit 1
Channel 127 bit 0
Channel 0 bit 7 tC16H tC16L
Channel 0 bit 6
WAN_CKLI tFOIS tFOIS WAN_FRMI tSTIH tSTIS WAN_STI tSTOD WAN_STO Channel 127 bit 1 Channel 127 bit 0 tSTOD Channel 0 bit 7 tSTIH tSTIS tSTIH tSTIS Ch0 bit7 tSTOD
Figure 40 - WAN Bus Slave Timing at 8.192 Mbs
84
Zarlink Semiconductor Inc.
MT90880/1/2/3
10.1.2 Clock Master Mode
Data format Parameter Symbol Min. Typ. Max.
Data Sheet
Units
Notes
ST-bus 8.192 Mbs mode
WAN_CLKO frequency WAN_CLKO High Width WAN_CLKO Low Width
fC16P tC16H tC16L fC4P tC4H tC4L fC2P tC2H tC2L tFOD tSTOD tSTIS tSTIH 5 5
16.384 30 30 4.096 122 122 2.048 244 244 25 25
MHz ns ns MHz ns ns MHz ns ns ns ns ns ns
ST-bus 2.048 Mbs mode
WAN_CLKO frequency WAN_CLKO High Width WAN_CLKO Low Width
Generic E1 2.048 Mbs mode
WAN_CLKO frequency WAN_CLKO High Width WAN_CLKO Low Width
All modes
WAN_FRMO Output Delay WAN_STO Delay WAN_STI Setup Time WAN_STI Hold Time
Table 32 - WAN Access Interface Timing - Master Mode
Channel 31 Bit 0 tC4L WAN_CLKO tFOD WAN_FRMO tSTIH tSTIS B0 tSTOD WAN_STO Ch 31 Bit 0
Channel 0 Bit 7 tC4H
Channel 0 Bit 6
tFOD
WAN_STI
tSTIH tSTIS B7 tSTOD Ch 0 Bit 7 Ch 0 Bit 6
Figure 41 - WAN Bus Clock Master Mode Timing at 2.048 Mbs
85
Zarlink Semiconductor Inc.
MT90880/1/2/3
Channel 31 Bit 0 WAN_CLKO tFOD WAN_FRMO tSTIH tSTIS WAN_STI tSTOD WAN_STO Ch 31 Bit 0 tSTOD Ch 0 Bit 7 tSTOD Ch 0 Bit 6 tSTIH tSTIS tFOD Channel 0 Bit 7 tC2H tC2L Channel 0 Bit 6
Data Sheet
tSTIH tSTIS
Figure 42 - WAN Bus Clock Master Mode at 2.048 Mbs - Generic E1 Mode
Channel 31 Bit 0 WAN_CLKO tFOD WAN_FRMO tSTIH tSTIS WAN_STI tSTOD WAN_STO Ch 31 Bit 0
Channel 0 Bit 7 tC2H tC2L
Channel 0 Bit 6
tFOD
tSTIH tSTIS
tSTIH tSTIS
tSTOD Ch 0 Bit 7
tSTOD Ch 0 Bit 6
Figure 43 - WAN Bus Clock Master Mode Timing at 8.192 Mbs
10.2
Local TDM Interface
Parameter Symbol Min. Typ. Max. Units Notes
Clock C16OB frequency Clock C16OB High Width Clock C16OB Low Width Clock C8OB frequency Clock C8OB High Width Clock C8OB Low Width Clock C4OB frequency
fC16F tC16H tC16L fC8F tC8H tC8L fC4F
16.384 30 30 8.192 61 61 4.096
MHz ns ns MHz ns ns MHz
Table 33 - Local TDM Interface Timing
86
Zarlink Semiconductor Inc.
MT90880/1/2/3
Clock C4OB High Width Clock C4OB Low Width C*OB to FP*OB delay WAN_STO Delay LOC_STI Setup Time LOC_STI Hold Time tC4H tC4L tFOD tSTOD tSTIS tSTIH 5 5 122 122 25 25 ns ns ns ns ns ns
Data Sheet
Table 33 - Local TDM Interface Timing (continued)
Channel 31 Bit 0 tC4L C4OB tFOD FP4OB tSTIH tSTIS LOC_STI tSTOD LOC_STO Ch 31 Bit 0
Channel 0 Bit 7 tC4H
Channel 0 Bit 6
tFOD
tSTIH tSTIS
tSTOD Ch 0 Bit 7 Ch 0 Bit 6
Figure 44 - Local Bus Timing at 2.048 Mbs
Channel 63 Bit 0 tC8L C8OB tFOD FP8OB tSTIH tSTIS LOC_STI tSTOD LOC_STO Ch 63 Bit 0
Channel 0 Bit 7 tC8H
Channel 0 Bit 6
tFOD
tSTIH tSTIS
tSTOD Ch 0 Bit 7 Ch 0 Bit 6
Figure 45 - Local Bus Timing at 4.096 Mbs
87
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
Channel 127 Bit 0 tC16L
Channel 0 Bit 7 tC16H
Channel 0 Bit 6
C16OB tFOD FP16OB tSTIH tSTIS LOC_STI tSTOD LOC_STO Ch 127 Bit 0 Ch 0 Bit 7 tSTOD Ch 0 Bit 6 tSTIH tSTIS tFOD
Figure 46 - Local Bus Timing at 8.192 Mbs
10.3 10.3.1
Packet Interface MII Transmit
Data for the MII packet switching is based on Specification IEEE Std 802.3u - 1995.
10 Mbs Parameter Symbol Min. Typ. Max. Min. Typ. Max. 100 Mbs Units
TXCLK period TXCLK high time TXCLK low time TXCLK rise time TXCLK fall time TXCLK rise to TXD active delay TXCLK to TXEN active delay
tCC tCHI tCLO tCR tCF tDV tEV
140 140 0 0
400 -
260 260 5 5 25 25
14 14 0 0
40 -
26 26 5 5 25 25
ns ns ns ns ns ns ns
Table 34 - Packet Interface Timing - MII Transmit
88
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
tCC TXCLK tEV TXEN tDV TXD
tCHI
tCLO
tEV
Figure 47 - MII Port Transmit Characteristics
10.3.2
MII Receive
10 Mbs Parameter Symbol Min. Typ. Max. Min. Typ. Max. 100 Mbs Units
Data input setup time Data input hold time Data valid input setup time Data valid input hold time RXCLK high wide time RXCLK low wide time RXCLK rise time RXCLK fall time RXCLK period
tDS tDH tDVS tDVH tCH tCL tCR tCF tCC
10 5 10 5 140 140 -
200 200 400
260 260 5 5 -
10 5 10 5 14 14 -
20 20 40
26 26 5 5 -
ns ns ns ns ns ns ns ns ns
Table 35 - Packet Interface Timing - MII Receive
tCC RXCLK tDVS RXDV tDH tDS RXD
tCHI
tCLO
tDVH
Figure 48 - MII Port Receive Characteristics
89
Zarlink Semiconductor Inc.
MT90880/1/2/3
10.3.3 RMII Interface
Parameter Symbol Min. Typ. Max. Units Notes 50 ppm
Data Sheet
Clock Frequency Clock Duty Cycle Setup Time to Clock Rising Edge RXD[1:0], CRS_DV Hold Time from Clock Rising Edge RXD[1:0], CRS_DV TXD[1:0] TX_EN Output delay tS tH tDV 35 4 2
50 65
MHz % ns ns 14 ns
Table 36 - Packet Interface Timing - RMII Interface
10.4
External Memory Interface
Parameter Symbol Min. Typ. Max. Units Notes
S_CLK to Data Out Valid Delay (RAM_D) S_CLK to Signal Valid Delay (RAM_A, RAM_ADSC#, RAM_RW, RAM_OE) RAM_D setup time before S_CLK rising edge RAM_D hold time after S_CLK rising
TRDV TRAV
10 7.5
ns ns
TRDS TRDH
3 0
ns ns
Table 37 - External Memory Timing
90
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
1 SCLK Trav RAM_A Trav RAM_ADSC RAM_RW
2
3
4
5
6
A1
Trav RAM_OE Trdh Trds D1
RAM_D
Figure 49 - External RAM Single Cycle Read
1 S_CLK
2
3
4
5
6
7
8
RAM_A
Trav A1 Trav
A2
A3
A4
RAM_ADSC Trav RAM_OE Trav RAM_RW Trdh Trds D1 D2 Trav
RAM_D
D3
D4
Figure 50 - External RAM Multi Cycle Read
91
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
1 S_CLK Trav RAM_A Trav RAM_ADSC Trav RAM_RW RAM_OE
2
3
4
5
6
A1
Trdv RAM_D D1
Figure 51 - External RAM Single Cycle Write
1
2
3
4
5
6
7
S_CLK Trav RAM_A Trav RAM_ADSC Trav RAM_RW RAM_OE Trdv RAM_D D1 D2 D3 D4 A1 A2 A3 A4
Figure 52 - External RAM Multi Cycle Write
92
Zarlink Semiconductor Inc.
MT90880/1/2/3
10.5 System Control Port
Parameter Symbol Min. Typ. Max. Units Notes
Data Sheet
System Clock Frequency System Clock Accuracy (synchronous mode) System Clock Accuracy (asynchronous mode)
CLKFR CLKACS CLKACA
66
32 200
MHz ppm ppm
Notes 1 and 2 Note 3 Note 4
Table 38 - System Clock
Note 1: The System clock frequency stability affects the holdover-operating mode of the DPLL. Holdover Mode is typically used for short durations while network synchronisation is temporarily disrupted. Drift on the system clock directly affects the Holdover Mode accuracy. Note that the absolute system clock accuracy does not affect the Holdover accuracy, only the change in the system clock (S_CLK) accuracy while in Holdover. For example, if the system clock oscillator has a temperature coefficient of 0.1 ppm/0 C, a 100C change in temperature while the DPLL is in the Holdover Mode will result in a frequency accuracy offset of 1 ppm. The intrinsic frequency accuracy of the DPLL Holdover Mode is 0.06 ppm, excluding the system clock drift. The system clock frequency affects the operation of the DPLL in free-run mode. In this mode, the DPLL provides timing and synchronisation signals which are based on the frequency of the master clock (S_CLK) only. The free-run frequency accuracy of the DPLL is 0.005 ppm plus the accuracy of the master clock (i.e. frequency of clock output C8OB equals 8.192 MHz S_CLK_accuracy 0.005 ppm). The absolute S_CLK accuracy must be controlled to 32 ppm in synchronous mode to enable the internal DPLL to function correctly. In asynchronous mode the DPLL is not used. Therefore the tolerance on S_CLK may be relaxed slightly.
Note 2:
Note 3: Note 4:
10.6
JTAG Interface
Parameter Symbol Min. Typ. Max. Units Notes
TCK Frequency of Operation TCK Cycle time TCK Clock pulse width TCK rise and fall time TRST Setup time to TCK falling edge TRST Assert time Input data setup time Input data hold time TCK to Output data valid TCK to Output data high impedance TMS, TDI Data setup time TMS, TDI Data hold time TCK to TDO data valid TCK to TDO High impedance tRSTSU tRST tJSU tJH tJDV tJZ tTPSU tTPH tTPODV tTPZ tCYC tLOW, tHIGH
0 40 20 0 10 10 5 15 0 0 5 15 0 0
10
25 3 30 30 15 15
MHz ns ns ns ns ns ns ns ns ns ns ns ns ns Note 2 Note 2 Note 3 Note 3 Note 1
Table 39 - JTAG Interface
Note 1: Note 2: Note 3: TRST is an asynchronous signal. The setup time is for test purposes only Non Test (other than TDI and TMS) signal input timing with respect to TCLK Non Test (other than TDO) signal output timing with respect to TCLK
93
Zarlink Semiconductor Inc.
MT90880/1/2/3
Data Sheet
tLow tCYC JTAG Clock Timing tRST TRST
tHIGH
tRSTSU
Figure 53 - JTAG Clock and Reset Timing
94
Zarlink Semiconductor Inc.
MT90880/1/2/3
11.0
ATM CBR CDP CES DBCES DMA DPLL DSP
Data Sheet
Glossary
Asynchronous Transfer Mode Constant Bit Rate Context Descriptor Protocol (used to indicate the contents of a packet stream or "context") Circuit Emulation Services Dynamic Bandwidth Circuit Emulation Services Direct Memory Access Digital Phase Locked Loop Digital Signal Processor
H.100/H.110 High capacity TDM backplane standards HDLC H-MVIP IP JTAG LAN MAC MII MIB PBSRAM PCI PDV PLL PPP PRBS PSTN QoS RMII SSRAM ST BUS TDM WAN WFQ WRED ZBT 0x 0b
High-Level Data Link Control High-performance Multi-Vendor Integration Protocol (a TDM backplane standard) Internet Protocol Joint Test Algorithms Group (generally used to refer to a standard way of providing a board-level test facility) Local Area Network Media Access Control Media Independent Interface Management Information Base Pipelined Burst SRAM (a type of synchronous SRAM) Peripheral Component Interconnect Packet Delay Variation Phase Locked Loop Point to Point Protocol Pseudo-Random Bit Sequence Public Switched Telephone Circuit Quality of Service Reduced Media Independent Interface Synchronous Static Random Access Memory Standard Telecom Bus, a standard interface for TDM data streams Time Division Multiplexing Wide Area Network Weighted Fair Queuing Weighted Random Early Discard Zero Bus Turnaround, a type of synchronous SRAM Denotes Hexadecimal notation Denotes binary notation
95
Zarlink Semiconductor Inc.
c Zarlink Semiconductor 2003 All rights reserved.
Package Code Previous package codes
ISSUE ACN DATE APPRD.
For more information about all Zarlink products visit our Web Site at
www.zarlink.com
Information relating to products and services furnished herein by Zarlink Semiconductor Inc. or its subsidiaries (collectively "Zarlink") is believed to be reliable. However, Zarlink assumes no liability for errors that may appear in this publication, or for liability otherwise arising from the application or use of any such information, product or service or for any infringement of patents or other intellectual property rights owned by third parties which may result from such application or use. Neither the supply of such information or purchase of product or service conveys any license, either express or implied, under patents or other intellectual property rights owned by Zarlink or licensed from third parties by Zarlink, whatsoever. Purchasers of products are also hereby notified that the use of product in certain ways or in combination with Zarlink, or non-Zarlink furnished goods or services may infringe patents or other intellectual property rights owned by Zarlink. This publication is issued to provide information only and (unless agreed by Zarlink in writing) may not be used, applied or reproduced for any purpose nor form part of any order or contract nor to be regarded as a representation relating to the products or services concerned. The products, their specifications, services and other information appearing in this publication are subject to change by Zarlink without notice. No warranty or guarantee express or implied is made regarding the capability, performance or suitability of any product or service. Information concerning possible methods of use is provided as a guide only and does not constitute any guarantee that such methods of use will be satisfactory in a specific piece of equipment. It is the user's responsibility to fully determine the performance and suitability of any equipment using such information and to ensure that any publication or data used is up to date and has not been superseded. Manufacturing does not necessarily include testing of all functions or parameters. These products are not suitable for use in any medical products whose failure to perform may result in significant injury or death to the user. All products and materials are sold and services provided subject to Zarlink's conditions of sale which are available on request.
Purchase of Zarlink's I2C components conveys a licence under the Philips I2C Patent rights to use these components in and I2C System, provided that the system conforms to the I2C Standard Specification as defined by Philips. Zarlink, ZL and the Zarlink Semiconductor logo are trademarks of Zarlink Semiconductor Inc. Copyright Zarlink Semiconductor Inc. All Rights Reserved.
TECHNICAL DOCUMENTATION - NOT FOR RESALE

▲Up To Search▲

Price & Availability of MT90883

	To Download MT90883 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .